I have submitted the following bug to trolltech and they found out that it must be a gentoo issue since it could only reproduced on gentoo machines, whereas ubuntu, Suse etc. remained unaffected. I have put the whole correspondence between, trolltech, ahigerd (a qt guru from the #qt irc channel at freenode) and myself below. This is a huge amount of material, I know, but I think it will make it easier for you to track down the bug if you read it all first. Thanx in advance momesana -------- Initial Email to trolltech ------------ =========== Info =========== System one: Distro: Gentoo x86 Gcc: 3.3.6 Qt: Qt-4.1.2 System two: Distro: Gentoo x86 Gcc: 3.4.5 Qt: Qt-4.1.1, Qt-4.1.2 (Qt-4.0.1 and Qt-4.1.0 do not have this issue) Hi, I've stumbled upon a anomaly in Qt that I think is a bug. I encounterd it when I was creating a QWidget derived Widget that contains a VBoxLayout that contains 60-70 QWidget-derived sub-widgets all stacked up in a row () http://www.informatik.uni-bremen.de/~momesana/app-portage/servant/servant.png. The elements can be filtered using a combo box. This hides and shows the Widgets as needes so they do not need to be removed from the Layout. Doing this I found a problem with Qt that was reproducable on 3 different gentoo machines. The problem is that after calling QLayout::setEnabled(...) on a layout to make changes in the layout visually smoother causes redraw issues. The widgets are blank and not repainted when the window is shaded/unshaded, minimized/maximized, coverd by other windows or even if you switch to another virtual desktop and switch back. Only resizing the window or other operations that force a repaint make the widgets display correctly. Since I have selfcompiled versions of Qt-4.0.1, Qt-4.1.0, Qt-4.1.1 (compiled by portage) and Qt-4.1.2 available I could test all of them to see when the bug was introduced. Qt-4.0.1 and Qt-4.1.0 were not affected but on the other hand they seem to not really respect the layout->setEnabled(false) statement. The same applies to windows where the redraw issue does not occur. Another gentoo user who isolated the problem in the code and created the example code you will find beneath has also created an animated gif that shows how the redraw issue looks like. Note that, when trying out the code, you have to at least change the value in the comboBox once so that the setEnabled(false) statement is called at all. One thing I do not really understand, is that in this version of code you see below, the redraw issue only happens when the comboBox is set to "all" again after changing its value at least once. That does not really make sense to me since the setEnabled(false) statement is called every time the slot is called but I am out of Ideas anyway ... :-) Thanx in advance momesana Here is the animated gif: http://afe-coda.cjb.net/~coda/gallery/view.php?user=admin&iid=12 There is a link beneath the image that points to the code pasted in some pastebin. But in case it is not available here is the same code: - ------------------------------ code ------------------------------------- #include <QApplication> #include <QLayout> #include <QComboBox> #include <QLabel> #include <QString> #include <QScrollArea> class Widgets : public QScrollArea { Q_OBJECT public: Widgets(); private: QComboBox *comboBox; QWidget* widgetList[60]; QVBoxLayout* layout; private slots: void updateList(const QString&); }; Widgets::Widgets() : QScrollArea() { QWidget* w = new QWidget(this); setWidget(w); setWidgetResizable(true); layout = new QVBoxLayout(w); comboBox = new QComboBox(w); comboBox->addItem("all"); comboBox->addItem("even"); connect(comboBox, SIGNAL(activated(const QString&)), this, SLOT(updateList(const QString&))); layout->addWidget(comboBox); for (int i=0; i < 60; i++) { widgetList[i] = new QWidget(); QLabel* l = new QLabel(QString::number(i), widgetList[i]); QHBoxLayout* hl = new QHBoxLayout(widgetList[i]); hl->addWidget(l); layout->addWidget(widgetList[i]); } } void Widgets::updateList(const QString& str) { layout->setEnabled(false); int flag = (str=="all"?-1:1); for(int i=0; i<60; i++) widgetList[i]->setVisible(i%2!=flag); layout->setEnabled(true); } int main(int argc, char* argv[]) { QApplication app(argc, argv); Widgets mw; mw.show(); return app.exec(); } - ------------------------ end of code ------------------------------- --------- Response from Trolltech ----------------- I was not able to reproduce this behavior locally, using Qt 4.1.0, Qt 4.1.1 or Qt 4.1.2. I am using an Ubuntu/Fluxbox system, and Qt versions drawn from our ftp server : ftp://ftp.trolltech.com/qt/source Further testing on 2 separate Suse Boxes has also failed to successfully reproduce the error After obscuring the window in question, the widget remains perfectly painted. The code looks good, although visual updates are normally suspended through the use of QWidget::setUpdatesEnabled(bool) rather then through QLayout::setEnabled(bool). This approach is documented here : http://doc.trolltech.com/4.1/qwidget.html#updatesEnabled-prop Thanks for the example code, the animated example and for the feedback. We appreciate the feedback, and please keep us informed if you discover any further information that could help us to isolate the cause of this problem. Kind regards, Donald ---------------- objection from ahigerd ------------------- We used QLayout::setEnabled() and QWidget::setUpdatesEnabled(), each separately and also together. The presence or absence of the setUpdatesEnabled had no effect on the rendering issue; we'll probably put it in the final code of the project for aesthetics, but it doesn't have any impact on the problem. We had disabled QLayout::setEnabled() for performance; there was significant overhead in allowing the layout manager to move around the remaining widgets due to the loop (O(n2) performance -- each time we hide a widget, the layout manager has to update all of the widgets) so we turned off the manager for the loop. We asked some users from irc.freenode.net#qt to test our sample code as well. One SuSE user and one Ubuntu user were unable to reproduce it, but a different SuSE user saw the issue. ---------------- Final answer from trolltech --------------- I have not been able to reproduce this bug on a machine running our official packages. We could reproduce it on a Gentoo box using a portage release of Qt 4.1.2, but the same box functioned perfectly when using the official Qt release packages. This seems to be a Gentoo bug, and should be reported to them. It is possible that the SuSE user who reproduced the error was using a similarly patched version. The official packages can be downloaded from : ftp://ftp.trolltech.com/qt/source Thanks for the feedback and continued aid in tracking down this bug. Kind regards, Donald ---------- emerge --info ---------------- emerge --info Portage 2.1_pre9-r4 (default-linux/x86/2005.1, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-reiser4-r1 i686) ================================================================= System uname: 2.6.15-reiser4-r1 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-mtune=athlon-xp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-mtune=athlon-xp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X a52 acpi alsa apache2 apm arts asf avi berkdb bidi bitmap-fonts bluetooth cli crypt cups dbus dga dlloader doc dri dv dvd dvdread eds emboss encode fame flash foomaticdb fortran gdbm gif gpm gstreamer gtk gtk2 imlib innodb ipv6 isdnlog jpeg kde kdeenablefinal kdexdeltas libg++ libwww lzo mad mikmod mjpeg mmx mmxext motif mp3 mpeg musicbrainz ncurses nls nptl ogg oggvorbis opengl oss pam pcre pdflib perl pic png pppd python qt quicktime readline real reflection sdl session spell spl sse ssl subtitles svg tcpd theora tidy truetype truetype-fonts type1-fonts unicode v4l vcd vidix visualization vorbis win32codecs xcomposite xine xml2 xmms xorg xpm xv zlib elibc_glibc input_devices_evdev input_devices_mouse input_devices_keyboard input_devices_joystick kernel_linux linguas_de userland_GNU video_cards_nv video_cards_nvidia video_cards_fbdev video_cards_vesa" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS ----------- end of emerge --info ----------------
I appreciate the detail of the bug. We don't do anything special with qt-4.1.x in Gentoo. We download, compile, and install it just like you could do manually. I would suspect if you downloaded qt from troltlech and compiled and installed it yourself, you'd see hte same results on a Gentoo machine. More likely, this is a window manager or X related. What WM are you using? What version of X?
I'm not sure what we can do to fix the issue. I hope it's working okay for you in Qt-4.2, but if you have any more insights please let me know.
(In reply to comment #2) > I'm not sure what we can do to fix the issue. I hope it's working okay for you > in Qt-4.2, but if you have any more insights please let me know. > AFAIK, the issue dissappeard with the release of Qt-4.1.3.
