I was wondering why it seems that Qt4-only applications looked so ugly in my KDE4.2 environment and it turned out that Qt seems unable to get the color scheme used by KDE4. I can use qtconfig and if I select QtCurve*, then it gets the color scheme. But after "File->Save" and "File->Exit" the scheme is lost. The next time I start qtconfig, the style is right, but the color scheme seems to be the one from kde3 (which I still have installed) * QtCurve is not present until I select Oxygen, File->Save, File-Exit, and open qtconfig again. Reproducible: Always Steps to Reproduce:
What is your qt-version? Did you upgrade all qt-packages to 4.4.2? Did you try to rebuild your kdelibs-4* to make sure that kdelibs pick the correct qt headers?
(In reply to comment #1) > What is your qt-version? When I filed the bug it was 4.4.2. > Did you upgrade all qt-packages to 4.4.2? Yes > Did you try > to rebuild your kdelibs-4* to make sure that kdelibs pick the correct qt > headers? Yes. In fact kde4 was compiled days after Qt. Now I'm running qt-copy (qting-edge) and it seems the same thing happens. The one that fixes the problem is Qt-4.5beta1, but KDE4.2 doesn't work with it.
I am sorry but I cant verify this on two separate gentoo machines running kde-4.1.96 and qt-4.4.2/qt-4.9999 respectively. Also im not sure how to reproduce it. I can se "QtCurve" no matter what theme i have selected
Then forget the style. Are the colors correct in your boxes?
Created attachment 179287 [details] qtconfig wrong colors this screen shot shows oxygen as style, but the colors are wrong. see the difference with systemsettings.
Created attachment 179288 [details] colors are ok This one shows the very same qtconfig instance, but after selecting QtCurve, and then back to oxygen. See what I mean? If I save the configuration, after a qtconfig restart, the colors are wrong again. This is fixed in qt-4.5-beta1.
I think I can see what you mean. But note that you are using beta software ( Kde-4.2, qt-4.9999, qt-copy, qt-4.5 are all in beta or live phase ) so it is normal to encounter several issues. So for now, I am closing at invalid, since it is impossible to provide support on live software. If you feel that the same thing happens again when all those packages reach stable state please feel free to reopen. I would also suggest, since you are using kde-4.2 , upgrade to qt-4.5.0_beta1 or qt-4.9999 . Afaik, kde-4.2 will be on Qt-4.5 when it is officially released :)
GRRRRR... How can you be so obtuse? Beta software is what I use to spot bugs. If I wanted a working desktop I would use Mac OS X! And the bug is present in Qt-4.4.3 which is stable in Gentoo. BTW: http://bugs.kde.org/show_bug.cgi?id=153056 (the server it's down right now) It's a qt bug _fixed_ in qt-4.5. Qt < 4.5 looks for the colors in the wrong path. I'll try to identify the patch.
(In reply to comment #7) > I would also suggest, since you are using kde-4.2 , upgrade to qt-4.5.0_beta1 > or qt-4.9999 . Afaik, kde-4.2 will be on Qt-4.5 when it is officially released > :) KDE-4.2 will be <Qt-4.5.
The fix, with patch included: http://bugs.kde.org/show_bug.cgi?id=168200#c15 Qt looks for colors in $HOME/.kde which -in my system at least- points to .kde3.5. Now OT to this bug: if you're not going to read/research, don't touch bugzilla. Your attitude is the kind of approach that make users angry. Read/listen to users. When they say there's a problem, there probably is a problem. That's one of the things I like about Ubuntu. The first thing you'll read in _every_ bug reports is: "thanks for your time in reporting this bug and help making ubuntu better" or something like that. They make users a priority. That's why they are #1 since a few years now.
I wont follow your attitude to attack developers for their decision. You want this re-opened? Lets re-open it then. The fact that I cant reproduce it here with same two different qt versions and kde-4.1.96 seems to me that there is something wrong with your Qt. I ll again to reproduce it here (again).
I ll try to apply this patch on current Qt-gui package. If this doesnt break anything on kde-3.5 colors I ll commit it. Could you please try qt-4.9999 from qting-edge and see if the problem is completed gone? As far as I understand the patch is already applied under qt-4.5.0_beta1. I ll do my tests and reply back
I didn't attack you. You closed the bug without research. I won't go into this again. So let's go back to the bug: The problem is the symlink .kde in $HOME. It points to $HOME/.kde3.5 here and so <Qt-4.5 reads its color scheme from kde3 config files. Perhaps you don't have kde3 and that's why you're not seeing this bug. qt-4.4.9999 (I guess you made a typo) didn't fix it. I built it yesterday. I can built it again if you want. qt-4.5beta1 fixes it. but it makes plasma crash. And have some other issues with kdm. I have built qt-gui-4.4.3-r1 with this patch but: * it fixes the bug if you define $KDEHOME or * you remove the symlink .kde $KDEHOME is not defined in Gentoo, and AFAIK that's the way everybody wants it to be. If I remove the .kde symlink, I think I'll break some kde3 config files since some of them have /home/zoolook/.kde/share/whatever... inside. I have not tested this in kde3 yet so I'm not sure what I'll break. I'll test this as soon as I commit this... see you in a few minutes.
The patch has been applied for testing on qting-edge overlay (qt-gui-4.4.9999 package). It applies ok but needs further testing to make sure it doesnt break stuff
whoa!!! startkde (kde3), recreates the symlink. I forgot about that one. So you use kde3, or kde4, but no both. or you could modify startkde (kde4) so it points the symlink to the current kde4 version (.kde4.2 here). this would fix the bug without patching qt.
(In reply to comment #14) > The patch has been applied for testing on qting-edge overlay (qt-gui-4.4.9999 > package). It applies ok but needs further testing to make sure it doesnt break > stuff Thanks!
(In reply to comment #15) > whoa!!! startkde (kde3), recreates the symlink. I forgot about that one. So you > use kde3, or kde4, but no both. > > or you could modify startkde (kde4) so it points the symlink to the current > kde4 version (.kde4.2 here). this would fix the bug without patching qt. > Actually, there are many users that still use kde-3.5. Lets keep this patch under qt-copy live ebuild for now until we verify that it doesnt break anything on kde-3.5. Lets keep it that way for now ,until we verify it doesnt break kde3 stuff :)
(In reply to comment #17) > Actually, there are many users that still use kde-3.5. yeah.. me for example. I didn't like kde4 until now. > Lets keep this patch > under qt-copy live ebuild for now until we verify that it doesnt break anything > on kde-3.5. Lets keep it that way for now ,until we verify it doesnt break kde3 > stuff :) It's ok for me. I'll reemerge qt-copy. Let me know if you need some special testing on KDE and/or Qt. I'm on vacation and I have some free time until 2/2/09 :) Thanks again, Norberto
(In reply to comment #18) > (In reply to comment #17) > > Actually, there are many users that still use kde-3.5. > > yeah.. me for example. I didn't like kde4 until now. > > > Lets keep this patch > > under qt-copy live ebuild for now until we verify that it doesnt break anything > > on kde-3.5. Lets keep it that way for now ,until we verify it doesnt break kde3 > > stuff :) > > It's ok for me. I'll reemerge qt-copy. > > Let me know if you need some special testing on KDE and/or Qt. I'm on vacation > and I have some free time until 2/2/09 :) > > Thanks again, > Norberto > This patch is on qt-gui so you just need to re-emerge qt-gui-4.4.9999 only :) I will try this patch on qt-gui-4.4.2 as well on kde3. Please do the same as you are more familiar on how to reproduce it . If we confirm that this package doesnt break stuff on kde3, I ll talk to maintainer about pushing it to the tree :)
(In reply to comment #19) > This patch is on qt-gui so you just need to re-emerge qt-gui-4.4.9999 only :) Actually I'm running qt-4.4.2 right now (patched) I'll test this a few days with this configuration as this is the stable Qt version in Gentoo. I'll report back in a few days.
(In reply to comment #20) > (In reply to comment #19) > > This patch is on qt-gui so you just need to re-emerge qt-gui-4.4.9999 only :) > > Actually I'm running qt-4.4.2 right now (patched) > > I'll test this a few days with this configuration as this is the stable Qt > version in Gentoo. I'll report back in a few days. > I dont mind testing qt-gui-4.4.9999 that match. If you run a patched qt-gui-4.4.2 is even better :). I am currently building qt-gui-4.4.2 on kde3 to see what will happen :)
Created attachment 179351 [details, diff] Proposed patch I am attaching the patch here if somebody else wants to test it
Created attachment 179353 [details] diff to current qt-gui ebuild Diff to current qt-gui ebuild. Seems to work fine on kde3 so far..
Well, I have a problem: with the code. If you look at it, it basically says to look for color in kdeglobalrc. This file can be located with the following method: QString QApplicationPrivate::kdeHome() { static QString kdeHomePath; if (kdeHomePath.isEmpty()) { kdeHomePath = QString::fromLocal8Bit(qgetenv("KDEHOME")); if (kdeHomePath.isEmpty()) { QString session = QString::fromLocal8Bit(qgetenv("DESKTOP_SESSION")); QDir homeDir(QDir::homePath()); QString kdeConfDir(QLatin1String("/.kde")); if (session == QLatin1String("kde4") && homeDir.exists(QLatin1String(".kde4"))) kdeConfDir = QLatin1String("/.kde4"); kdeHomePath = QDir::homePath() + kdeConfDir; } } return kdeHomePath; } It basically says that if you have $KDEHOME use that and stop, else look for $DESKTOP_SESSION, get $HOME, now check if: (SESSION==kde4 && exists .kde4), use $HOME/.kde4; else use $HOME/.kde Now the problem. DESKTOP_SESSION is KDE-4.2 here, and so the check fails and the method returns $HOME/.kde; in other words, it will still look into kde3 using the default Gentoo environment. Where is this $DESKTOP_SESSION defined/exported?
(In reply to comment #24) > Where is this $DESKTOP_SESSION defined/exported? /usr/share/xsessions I copied KDE-4.2.desktop to kde4.desktop. Restarted KDE4 using this "profile" and $DESKTOP_SESSION is now kde4 and the code works. Also, I have this symlinks in my home: zoolook@venkman ~ $ ls -ld .kde* lrwxrwxrwx 1 zoolook users 7 2009-01-22 15:04 .kde -> .kde3.5/ drwxr-xr-x 5 zoolook users 103 2008-07-12 01:40 .kde3.5/ lrwxrwxrwx 1 zoolook users 8 2009-01-22 15:18 .kde4 -> .kde4.2// drwxr-xr-x 6 zoolook users 132 2009-01-22 12:02 .kde4.2/ kde3 apps (amarok) gets its configuration from kde3, qtconfig (qt4) shows correct colors.
There are some weird stuff in here 1) echo $DESKTOP_SESSION is "default" here ( either with kde3 or 4 ) 2) on a kde4 only machine , i do have a .kde4 folder on $HOME. Seems to me that the code snipset needs some modification. Could you please tell me where this code is located in order to create a draft patch to cover as many situations as possible?
(In reply to comment #26) > Could you please tell me where this code is located in order to create a draft > patch to cover as many situations as possible? The very first method in the patch :)
Yeah, forget about it my mistake :) So, we basically need to have a .kde-4-X symlink under $HOME to make this patch work What if we use this code ** if (session != QLatin1String("kde3") && homeDir.exists(QLatin1String(".kde4"))) ** This will catch all kde-4.X Sessions. It might break other stuff if the DESKTOP_SESSION is not a KDE-X one though...
(In reply to comment #28) > So, we basically need to have a .kde-4-X symlink under $HOME to make this patch > work and DESKTOP_SESSION=kde4 > What if we use this code > > ** > if (session != QLatin1String("kde3") && homeDir.exists(QLatin1String(".kde4"))) > ** > > This will catch all kde-4.X Sessions. It might break other stuff if the > DESKTOP_SESSION is not a KDE-X one though... Will break -for example- in your boxes. You told me in your kde3 "echo $DESKTOP_SESSION" was "default" and so in your kde3 Qt will look for colors in .kde4. You'll reintroduce the bug, just the other way around :) What we need is: symlinks: .kde => .kde3.x .kde4 => .kde4.x AND: $DESKTOP_SESSION needs to point to kde4. We can also write something like (pseudo-code): if DESKTOP_SESSION == (kde4* | KDE4* | kde-4*| KDE-4*): Or we could also get rid of the symlink hack and standarize KDE4 so it's $KDEHOME is $HOME/.kde4. Then you have only one problem: $DESKTOP_SESSION. IIRC the symlink hack was introduced 'cos kde3's config files were not compatible between minor versions. Someone correct me if I wrong.
Since this bug is not only Qt specific but also depends on kde ( maybe kdebase-startkde packages is responsible for thoses symlinks ) lets bring kde team into this too :)
I would even say this is more of a KDE issue than a Qt one. Can someone in the know elaborate why we don't define $KDEHOME?
(In reply to comment #31) > I would even say this is more of a KDE issue than a Qt one. Can someone in the > know elaborate why we don't define $KDEHOME? > Hm. This is wild guess actually, but I think $KDEHOME is deprecated because of the following scenario: * You have a working kde3 and kde4 environment. * You start kde4, but you want to use some applications that are still not ported to kde4. * You have those applications already configured in kde3. * You want to continue using alternatively kde3 and kde4. * If you define $KDEHOME and start that application in kde4, it will start with a fresh configuration, and if you swith environments, you will (probably) soon have a broken configuration/application.
As a gentoo kde dev told me, .kde* can change according to prefix usage or not. So , a simple modification to the below code --------------------------------------------- Old: if (session == QLatin1String("kde4") && homeDir.exists(QLatin1String(".kde4"))) New: if (session == QLatin1String("kde4") && homeDir.exists(QLatin1String(".kde4*"))) ---------------------------------------------------------- To much every .kde4 folder might fix it. Could you try this?
Yes. Of course. I'll try it tonight (we're in GMT-2) so I'll write tomorrow about the results.
(In reply to comment #33) > New: > if (session == QLatin1String("kde4") && > homeDir.exists(QLatin1String(".kde4*"))) doesn't work since QDir::exists() doesn't know what to do with wildcards. Two things for kde-team: 1) KDE 4.x is going to use "kde4" as DESKTOP_SESSION or will it continue to be "KDE-4.2", "KDE-4.3", etc? 2) What about the symlink at $HOME like in KDE3? Will there be a $HOME/.kde4 => .kde4.2 for example? Thanks, Norberto
(In reply to comment #35) > Two things for kde-team: Although offtopic, i'll give a quick answer but please i don't want further discussion here. > 1) KDE 4.x is going to use "kde4" as DESKTOP_SESSION or will it continue to be > "KDE-4.2", "KDE-4.3", etc? .kde4 is for -kdeprefix and .kde4.X is for +kdeprefix > 2) What about the symlink at $HOME like in KDE3? Will there be a $HOME/.kde4 => > .kde4.2 for example? No, there was one initially but we dropped it as there may be more than one kde4 installations in a single system, so it is only causing problems. > Thanks, > Norberto >
Is this still an issue or can this be closed?
4.4.2 is not on tree anymore. If problem persist with newer Qt releases, please re-open it
