General and Desktop

So, if it will be useful for anybody: @ // in *.h inline qreal curScale() const {return transform().m11();} // in *.cpp void MainView::scaleBy(qreal scaleFactor) { qreal curScaleFactor = transform().m11(); if (((curScaleFactor == minScale) && (scaleFactor < 1.0)) || ((curScaleFactor == maxScale) && (scaleFactor > 1.0))) return; qreal sc = scaleFactor; if ((curScaleFactor * sc < minScale)&&(sc < 1.0)) { sc = minScale / curScaleFactor; } else if ((curScaleFactor * sc > maxScale)&&(sc > 1.0)) { sc = maxScale / curScaleFactor; } scale(sc, sc); } void MainView::setZoom(int percentZoom) { qreal targetScale = (qreal)percentZoom / 100.0; qreal scaleFactor = targetScale / transform().m11(); scaleBy(scaleFactor); }@ I used only m11, cause in my case m11 == m22.

It does not matter if I use @WId QWidget::effectiveWinId () const@ or @ WId QWidget::winId () const@ Both functions return the same value for my widget. I can use the returned handle to register it with my raw input device but Qt calls the function @bool QWidget::winEvent(MSG * message, long * result)@ of the widget that returned the native windows handle only, if the active and focused window contains a widget that can get the input focus. So the native windows handle of a QWidget is not suitable for use with Win32 raw input API. Therefore I need a valid handle of the applications core window (not the main window). A possible solution would be to use the qWinAppInst() function to get a native Win32 hInstance value and to find the core application window via Win32 function calls: @DWORD ProcIDFromWnd(HWND hWnd) { DWORD ProcId; GetWindowThreadProcessId(hWnd, &ProcId); return ProcId; } HWND qGetNativeAppWindow() { HWND tempHwnd = 0; // Grab the first window handle that Windows finds: tempHwnd = FindWindow(0, 0); HINSTANCE hInstance = qWinAppInst(); do { // Check if no parent for this window if (GetParent(tempHwnd) == 0) { DWORD ProcId = ProcIDFromWnd(tempHwnd); HINSTANCE AppInstance = (HINSTANCE)GetWindowLong(tempHwnd, GWL_HINSTANCE); if (AppInstance == hInstance) { #ifdef GWLP_USERDATA QAbstractEventDispatcher *q = (QAbstractEventDispatcher *) GetWindowLongPtr(tempHwnd, GWLP_USERDATA); #else QAbstractEventDispatcher *q = (QAbstractEventDispatcher *) GetWindowLong(tempHwnd, GWL_USERDATA); #endif if (q == QAbstractEventDispatcher::instance()) { return tempHwnd; } } } tempHwnd = GetWindow(tempHwnd, GW_HWNDNEXT); } while (tempHwnd != 0); return tempHwnd; } @ Or is there any better solution to implement raw input device support for Win32?

There are lots of ways to transmit data between applications. Just google for "inter process communication" and select any method that matches your use case best. Qt does support quiter a few natively and can be made to work with all the rest that have C or C++ libraries to access them.

Bug report has been generated. Here is the link: http://bugreports.qt.nokia.com/browse/QTBUG-12737

yes i wrote a small test prog and was able to replicate your problem. the actual behavior I noticed is as follows: when you undock if you ensure that the toolbar remains horizontal always, you still get back the custom icon, if the toolbar becomes vertical and then you try to dock it and resize, the custom icon is lost and the default is back. to check further ... seems a bug to me, you should log this bug.

Thanks, I reinstalled it, and no problem now.

does QPixmap::ShareMode have anything to do with this. It says on x11, you have to explicitly delete the pixmap handle. how would one use it? also, not related to leak, but I've found QImageReader to be more efficient in terms of memory footprint, you might cross check.. below from qt docs: @ QImageReader is a specialized class which gives you more control when reading images. For example, you can read an image into a specific size by calling setScaledSize(), and you can select a clip rect, effectively loading only parts of an image, by calling setClipRect(). Depending on the underlying support in the image format, this can save memory and speed up loading of images @

just a question, isn't it easier to just use @ QSvgRenderer *svgRender; svgRender = new QSvgRenderer(file_str); QImage *imageSvg = new .... @

how about a sh script that sets/exports LD_LIBRARY_PATH and then launch the creator.. won't this work?

Have you had a look here: "http://doc.qt.nokia.com/4.6/install-win.html":http://doc.qt.nokia.com/4.6/install-win.html ?

@aviral, qpainter allows u to clip regular raster images very well, I actually tried to use the same on a SVG image due to some requirement I had. Then noticed that svg clipping was not handled. Which other formats do you think we should target in the solution.

As far as I know SQLite supports NULL entries. Have u tried the QVariant.isNull() method to check if the value is NULL?

Please use code tags: @Robot::Robot() { (...) QGraphicsItemAnimation *headAnimation = new QGraphicsItemAnimation; headAnimation->setItem(headItem); headAnimation->setTimeLine(timeLine); headAnimation->setRotationAt(0, 20); headAnimation->setRotationAt(1, -20); headAnimation->setScaleAt(1, 1.1, 1.1); QGraphicsItemAnimation *upperLeftArmAnimation = new QGraphicsItemAnimation; upperLeftArmAnimation->setItem(upperLeftArmItem); upperLeftArmAnimation->setTimeLine(timeLine); upperLeftArmAnimation->setRotationAt(0, 190); upperLeftArmAnimation->setRotationAt(1, 180); }@ Otherwise: good question. It seems to me that the animations should be created with some kind of parent.

If you don't do it already: For an embedded target, you could use the auxiliary tool qconfig: see the keyword "Fine-Tuning Features in Qt" in the Qt documentation. It is a simple GUI that lets you select and de-select the features or class you want excluded. It makes sure that class depending on an excluded class are excluded, too. You cannot get rid of QWidget itself, because QGraphicsView inherits QWidget. But I would expect that most of the classes derived from QWidget should disappear. If you look at src/corelib/global/qfeatures.txt and search for "# Widgets", "# Dialogs", "# ItemViews", and "# Styles", you get a pretty good idea, what can and will be removed.

I am not too sure about the solution in Qt but having used Eclipse Plug in Development for some time what I feel is we need to have an ADAPTER that can adapt your QtScriptPlugin with QObject. To get the Adapter we need to explore what you mention in registering mechanism. Do let know where did u find the fix.

I think, no OCI drivers enough in your Qt-build. You must download Qt-source and build it with needed driver.

I'll ask there. Thank you. Anyway, why are two different sites to talk about Qt? Is not better to have everything in just one official site?

I haven't looked into 4.7, yet. Will do that now. Thanks for the hint.