In, for example, KDE's Info Centre, if I try to adjust column width I see ghost images of the previous setting (these disappear when I shade/unshade the window, forcing a repaint). I've seen this in other KDE apps as well, notably knoda and konqueror's MultiColumn View. I sent screen shots to Horst Knorr, knoda author, and he said "...this behaviour is controlled by Qt, not knoda, but I use the same qt-version as you and I don't have this bug..." It seems indeed to be a Qt-3.3.2 bug. Googling for "qt 3.3.2 columns" shows others had seen similar problems on the debian and kde mailing lists. I've downgraded to 3.2.3 (then remerged arts, kde*, knoda, hk_classes and the problem has disappeared.
Created attachment 35467 [details] knoda table view - resizing columns
I forgot :-) $ emerge info Portage 2.0.50-r9 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.8-rc1) ================================================================= System uname: 2.6.8-rc1 i686 AMD Athlon(tm) XP 3200+ Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /sbin /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /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/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache emergemail fixpackages nostrip notitles sandbox userpriv usersandbox" GENTOO_MIRRORS="http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/ http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib acpi apm arts artswrappersuid avi berkdb cdr crypt cups doc dvd dvdr encode esd faad fbcon foomaticdb ggi gif gimp gimpprint gphoto2 gpm gtk gtk2 gtkhtml imlib innodb java joystick jpeg kde libg++ libwww linguas_en_GB mad maildir mbox mikmod mmx mng motif mozilla moznoirc mozsvg mpeg mysql ncurses nls nocardbus odbc oggvorbis ooo-kde opengl oss pam pdflib perl png postgres ppds python qt quicktime readline samba scanner sdl slang spell sqlite sse svg tcltk tcpd tetex tiff truetype unicode usb wmf x86 xml2 xmms xv xvid zlib"
Ok, but what's the fix here?
Sorry, don't have one. Workaround is to add "=x11-libs/qt-3.3.2" to /etc/portage/package.mask (I added =x11-libs/qt-3.3.1-r2 as well to make sure), then emerge qt, arts and kde*. I would suggest masking qt-3.3.2.
I can now verify that these problems _don't_ exist with Qt-3.2.3 _or_ Qt-3.3.1. qt-bugs@trolltech.com - Issue N52713 refers
I can confirm this too, both with qt provided by gentoo and from trolltech. I've been using the same version on a Debian system (qt downloaded and compiled) without this bug.
so what we need is a patch. anyone know of one?
Ok, I've just found the problem and as nothing to do with Qt but with Qinx 1.1 style. After downgraded to 1.0 and now QTable is rendered correctly.
I've never used Qinx. Is that a KDE style? I don't see it in qtconfig either, so it's unlikely to have caused my problems. I'm using Baghira.
Yes, qinx is a kde style, I've been using it for a long time. When I switched to any other style the problem just disappear except with qinx, so I emerge the stable version and now I don't have any problems. Do you have the problem with other style as well?
Q: Do you have the problem with other style as well? A: I don't think I tried other styles apart from Baghira, which is the closest I've seen to Mosfet-Liquid. I'm currently building a binary package of Qt-3.3.1 (which I have currently installed). When that's done I'll remerge 3.3.2 and do some more testing.
Wrong answer, Peter. If there is no problem with the themes which ship with kde, then you should ask the author of baghira for a fix.
I remembered that since I downgraded Qt to 3.2.3 I had upgraded the baghira style to 0.4c. So I upgraded Qt to 3.3.2, remerged all the KDE stuff and started testing again. Problem has disappeared, so it looks like Filipe's comments #8 are correct and you should probably resolve this as invalid. I used Gentoo ebuilds for baghira, but the changelog hasn't been kept up-to-date, do I read the changelog on the kde-look site - perhaps there's a clue there?: Changelog: 0.4c ---- - (hopefully) fixed compiler stuff - code cleanup: later - redesigned the dialogs for the windeco 1024x768 compatible now (allmost 800x600 :) - fixed the toolbutton stuff - removed any listviewheader correction as this caused more problems that it could ever solve (if you worry about listviews, having too short headers and therefore paint void areas - complain to the appropriate author) ^^^^^^^^ perhaps relevant?? ***NOTICE*** with this release the button color is no more defined by the settings in your color group, but directly by the color picker in the config dialog. BAGHIRA WILL NOT CARE ABOUT THE BUTTON COLOR IN THE COLOR SETTINGS!!! (main reason for this is to allow setting button color to background for some apps like opera) I apologize for the noise.
Peter, ask the author. The only reason why the theme isn't hard masked (not because of this bug report) yet, is that quite a few Gentoo user are interested in it and would complain. :| And I have neither the time nor the interest to test all themes in-depth.
OK, I emailed the Baghira author and received this reply: From: Thomas L
OK, I emailed the Baghira author and received this reply: From: Thomas Lübking <thomas.luebking@web.de> "I don't use knoda, but i guess you mean this problem (if not: mail again!): The key problem is that some applications use listviewheaders that 1. do not expand to liestviewsize 2. do not finish with a virtual (empty) entry (e.g. k3b) To avoid unhappy flickering (at least qt 3.2.x ) when resizing listviews i set the background mode for listviewheaders to none (i.e. qt paints void - nothing. this is necessary due to the special look of the headers - the effect isn't as strong on styles like plastik) this does of course _not_ work if the header does not paint on the full region (producing those artefacts, which appear by simply not updating this region) i temporary tried to fix this by modifying the header expanding settings - what just lead to even more problems (i.e. in konqueror detail view) so either the solution has to come from the application side (adjust the header behaviour) or i'll have to find a very good trick, or qt updates their painting function... sorry about that" All is working well for me now with: KDE-3.2.3, Qt-3.3.2, baghira-0.4c
BTW, I copied the info from Comment #15 to: qt-bugs@trolltech.com hk-classes-discuss@lists.sourceforge.net
Thanks Peter, resolving upstream then.
