Technical FAQ

1. Why doesn't QWidget::setBackgroundColor() do what I expect?

   The documentation for setBackgroundColor explains the most common mistakes. The short version is usually to use either QPalette or QColorGroup instead.

2. Can Qt 1.x and 2.x co-exist on the same machine?

   Yes, see these guidelines.

3. How do I get a nonrectangular or transparent widget?

   Use QWidget::setMask(). Warning: Nonrectangular widgets are slow on some platforms.

4. Do I have to delete my child widgets?

   Ordinarily no. Child widgets will be automatically destroyed by the parent widget when that is destroyed. See the documentation of ~QObject() for details.

5. Can I use X11 overlays with the Qt OpenGL Extension?

   Yes, see the documentation of QGLWidget, and the README files in the overlay examples.

6. Can I use Windows APIs together with Qt? The compiler complains about redefinition of HDC etc.

   Yes, no problem. If you get such compilation failures, just make sure that you include the Qt header files before windows.h or other Windows heaader files everywhere in your code.

7. How can I write threaded programs?

   You must have a thread library and a libc which is compatible with that thread library, and thread-safe X11 libraries, and you must run the GUI in one thread, reacting to incoming events as usual. The Qt API may in general only be used from one thread.

   We know that people have done this on both Windows NT and on several Unixes.

   Brian P. Theodore has written some code to help with threading on X11/Unix. He sent a message about it to Qt-interest.

8. I have problems compiling <Qt or something related to it> on <platform>

   See the Installation FAQ.

9. You frequently say that you cannot add this or that feature because it would break binary compatibility. What does this mean, really?

   Binary compatibility means that you can safely distribute your Qt programs dynamically linked to the Qt library. If the users of your program have a newer version of the Qt dynamic library installed (or later upgrade to one), your program will still work. This can save much time, network, disk, and memory resources and adminstration work, for both you and the users of your Qt-based programs.

   Technically, this means, roughly ordered from least to most obvious:

   • We cannot add reimplementations of virtual functions, unless it it safe for older binaries to call the original implemenation. This is because the compiler evaluates SuperClass::virtualFunction() calls at compile-time, not at link-time.
   • We cannot add or remove virtual member functions. This would change the size and layout of the vtbl of every subclass.
   • We cannot change the type of any data members or move any data members that can be accessed via inline member functions.
   • We cannot change the class hierarchy, except to add new leaves.
   • We cannot add or remove private data members. This would change the size and layout of every subclass.
   • We cannot remove public or protected member functions unless they are inline.
   • We cannot make a public or protected member function inline.
   • We cannot change what an inline function does, unless the old version continues working.
   • We cannot change the access rights (i.e. public, protected or private) of a member function. Some compilers mangle the access rights into the function name.
10. Purify complains about UMRs (Uninitialized Memory Reads) in the QGDict constructor? Is this a bug in Qt?

    This is not a bug in Qt. You can safely ignore this message.

    QGDict uses bit field members to save space. When QGDict initializes its members, bits are either set or cleared. To clear a bit on assembly level, a byte is first read, AND'ed with a mask and written back. Purify reports a UMR when reading the byte. The UMR depends on your compiler and compiler options.

    We've seen such false UMRs in these places, among others, in Qt:

    • QGDict::QGDict()
    • QMenuData::QMenuData()
    • QPushButton::init()
    • QMenuItem::QMenuItem()
    • QScrollbar::QScrollbar()

    We've been in contact with PureAtria (now Rational), the maker of Purify, and they say this is a problem which cannot easily be solved. The only solution would be that the compiler first sets all bytes to zero before accessing the bits.

11. Purify found a memory leak in qapp_x11.cpp. Why don't you clean up the XIM (X Input Method) structure?

    This is to work around a bug in some versions of Xlib. The leak isn't harmful - it concerns only 400 bytes of memory which will be deallocated anyway when the application terminates.

12. Can I use Qt's classes without writing a graphical user interface?

    A few of the classes can be used independently of a GUI. See utility classes, for example. There are also a few classes that will work without the GUI only by chance.

13. I want to pop up a popup menu when I get a mouse event, but the menu pops up at wild places. (How do I convert local coordinates to global ones?)

    The QPoint argument to the QPopupMenu::popup() function takes global screen coordinates as its argument. The position sent to a mouse event is always in the widgets local coordinates. Positions can be transformed between the different coordinate systems with either QWidget::mapToGlobal(), QWidget::mapToParent(), QWidget::mapFromGlobal() or QWidget::mapFromParent().

    In the particular case with the mouse event, the correct way is to use the event's globalPos() function instead. Here is one way of doing it:

    void CustomWidget::mousePressEvent( QMouseEvent *event )
    {
        if ( event->button() == RightButton )
    	menu->popup( event->globalPos() );
    }

14. When a signal is emitted, will all of the slots attached to it be executed before the emit returns? Or are the slots just scheduled to be executed whenever convienient?

    All of the slots will be executed before the emit returns. The order of execution of the slots is undefined.

15. Why does not Qt use STL?

    The Standard Template Library, contrary to what the name implies, is not all that standardized (at least not yet); implementations differ, and some systems/compilers do not even have it yet. We prioritize very highly that Qt-based programs should be completely and easily portable across platforms and compilers, so we don't want to put STL-dependency in Qt until it is safe to do so.

    As for the string class, in Qt 2.0 there is a brand new QString class which is much more usable and efficient (using implicit sharing instead of explicit) than the 1.x QString, as well as covering internationalization through Unicode. The STL string is less usable and efficient.

    Still, it is no problem to use STL together with Qt, if you prefer. QStrings can easily be converted to STL strings and vice versa. Using the Qt tool classes (lists, stacks and so on) instead of the STL classes is optional, not obligatory.