I installed QT 3.3 this afternoon right after it came out and the KDE specific themes in /usr/kde/3.2/lib/kde3/plugins/ aren't listed in the KDE Styles control panel applet. It reverted to the 'Windows' look. The QT-specific themes are listed in the Styles control panel applet. What should I provide you for troubleshooting? emerge info? Reproducible: Always Steps to Reproduce: 1. 2. 3.
A re-emerge of kdebase may be helpful.
Caleb: May I attach my style problem here!? I merged kde with qt 3.2.3 and twice with qt 3.3., reported it to bugs.kde.org (declard invalid), but don't have a clue if this problem is kde or gentoo trelated. http://bugs.kde.org/show_bug.cgi?id=74337
Basically qt plugins are versioned. QT will check the version of the plugin and in case of an incompatible version (based on the qt version it was build against) will not use it. qt 3.3 and qt 3.2 plugins are obviously incompatible, so you need to remerge all packages that contain these plugins.
ps. plastik is from the kdeaddons package, so you'll need to remerge that too ;-/
No Paul. Plastik is part of kdeartwork and I remerged this ebuild too.
Argh - i just did it, recompiling kdeaddons fixed the problem, even though plastik is part of kdeartwork. Thx Paul!
I think we could try a hack to make the config build strings the same for 3.3 as for 3.2, but I'm not sure what else that would break.
There are good chances that the plugins will actually not work with a new qt version. We might need to check it out though.
http://doc.trolltech.com/3.3/plugins-howto.html It says: Two different configurations of the same version of the Qt library are not binary compatible. The Qt library that loads the plugin uses the list of (missing) features to determine if the plugin is binary compatible. Note: There are cases where a plugin can use features that are available in two different configurations. However, the developer writing plugins would need to know which features are in use, both in their plugin and internally by the utility classes in Qt. The Qt library would require complex feature and dependency queries and verification when loading plugins. Requiring this would place an unnecessary burden on the developer, and increase the overhead of loading a plugin. To reduce both development time and application runtime costs, a simple string comparision of the build keys is used. My guess is that the addition of the ipv6 code has caused this binary incompatibility, which is why the configuration option shows up in the buildstring.
A note in the Qt 3.3 ebuild would minimze forum/bugzilla support questions. ;)
You read my mind - just did it. I'm assuming that kdelibs is the main package to be need to be re-emerged (since it provides the styles), along with kdeartwork/kdeaddons. Dunno about kdebase...it provides designer plugins.
Okay, for those just finding this bug, the solution is you must recompile kdelibs and kdeartwork. kdebase and kdeaddons have no effect. It's a limitation of moving between QT versions. This should be all that was broken.
Changing the ebuild: - use ipv6 && myconf="${myconf} -ipv6" || myconf="${myconf} -no-ipv6" + use ipv6 && myconf="${myconf} -ipv6" Makes the buildstring look the same as from the 3.2.3 version, meaning that we may be able to avoid this step. Any thoughts?
Jason: Not remerging kdeaddons broke at least plastik .net style here.
I'm working on a system in the ebuild which notifies the user of a change to their QT_BUILD_KEY after upgradting Qt, but I'm not finding any slick way of doing it. I'm not sure if the new portage has some functionality I'm missing or what, but rest assured I'm trying to get this to be resolved a little nicer.
Created attachment 25512 [details] Screenshot After emerging qt-3.3.0, and re-emerging kdelibs-3.2.0 and kdeartwork-3.2.0, see what the K menu looks like with Plastik.
KDE external themes such as: x11-themes/baghira may also have to be manually reemerged... :-/ (baghira does)
I've got just the same problem. I tried to reemerge qt, kdelibs, but without success. I noticed something strange: I cannot emerge any Program, which uses the qtlib, but I can compile it on my own. When I do not use portage, to configure this programm, there are no failures. Can it be, that there is something wrong in the kde_source_compile funktion in theese ebuilds?
I figured out something else. The ./configure step works fine, if I change the configure script: I changed the line: ###code: if test -f actest.cpp && grep klineedit actest.cpp > /dev/null; then kde_cv_uic_plugins=yes fi Into if test -f actest.cpp && grep -i klineedit actest.cpp > /dev/null; then kde_cv_uic_plugins=yes fi I think, the problem ist the misspelled word: klineedit. It should be spelled: KLineEdit. With that, the configure step works fine, but the source code does not compile. It exits with different failures.
should all be propagated out of portage now.
