KDE4 style in Qt4 - how to compile KDE4 style in Qt 4.5

**pawelprazak** · 7th February 2009, 22:43

Hi!

I'm trying to get my kde4 style to work with Qt4 apps compiled from source with Qt 4.5 trunk. I have successfully compiled Arora (trunk) with Qt 4.5, but I don't know how to make styles work like Qt 4.4.3 bundled with my openSUSE 11.1 do.
I've searched the internet and this forum, as well as the documentation, but I couldn't find anything relevant. Could you give me a pointer to some resources or a hint?

Regards

**wysota** · 7th February 2009, 23:01

You mean you want a KDE style to work without KDE, right? In that case you need to strip out all KDE dependencies from it then build it and then install it under plugins/styles directory of your Qt installation. If you want to deploy it on another machine, follow the docs on deploying plugins.

**pawelprazak** · 9th February 2009, 20:01

Thank you for your quick reply and sorry I didn't write clear what I mean.
I have pure Qt4 application (Arora web browser) and I use it under KDE 4.2.
When I compile it with system Qt (4.4.3) it uses my KDE style, but when I compile it with Qt 4.5 compiled from source it doesn't support my KDE4 style.
Gnome styles seems to work fine, e.g ./arora -style=clearlooks, but Oxygen does not work.
I know I need style plugin, but I don't know how to do it.
I also use Qt Creator and I have two versions 0.9.2-rc1 and compiled from source (trunk). Both use my KDE4 style. I've been trying to find out how do they do it but with no luck so far.

Regards

**jens** · 14th February 2009, 08:53

You need to make sure that the style is the plugin path used by your custom built Qt. For instance you can try to copy your style plugin directly into QTDIR/plugins/styles. if that does not work you can use QT_DEBUG_PLUGINS to figure out if there are any dependencies preventing the style from loading.

**pawelprazak** · 14th February 2009, 13:35

Originally Posted by jens

You need to make sure that the style is the plugin path used by your custom built Qt. For instance you can try to copy your style plugin directly into QTDIR/plugins/styles. if that does not work you can use QT_DEBUG_PLUGINS to figure out if there are any dependencies preventing the style from loading.

Thank you for pointing me the right directionn

I've checked the plugins path, but it's ok and I've checked the QT_DEBUG_PLUGINS option:

"QFactoryLoader::QFactoryLoader() looking at "/usr/lib64/kde4/plugins/styles/oxygen.so"
"Cannot load library /usr/lib64/kde4/plugins/styles/oxygen.so: (/usr/lib64/libQtSvg.so.4: undefined symbol: _ZN14QObjectPrivate15checkWindowRoleEv)"
could not load"

So as far as I understand, oxygen.so uses my system qt (4.4.3) and its libQtSvg.so.4 isn't binary compatible with rest of the application compiled with 4.5, so I need to make it use my custom build one, right? I'm trying to figure out how to make KDE4 to use different qt libraries for one program, maybe there's some KDE's environment variable to do it. I has to be done somehow by Qt Creator...

[Edit]
> export QT_DEBUG_PLUGINS=1; qtcreator
QFactoryLoader::QFactoryLoader() looking at "/usr/lib64/kde4/plugins/styles/oxygen.so"
keys ("Oxygen")

It works with Qt Creator and it have it's own libs dir.

I've looked around a little bit more and this is what I've found:

~/dev/arora/build> readelf /usr/local/Trolltech/Qt-4.5.0/lib/libQtSvg.so.4 -a | grep QObjectPrivate
000000249590 014600000001 R_X86_64_64 0000000000000000 _ZTI14QObjectPrivate + 0
000000249830 014600000001 R_X86_64_64 0000000000000000 _ZTI14QObjectPrivate + 0
00000024a7a0 014000000007 R_X86_64_JUMP_SLO 0000000000000000 _ZN14QObjectPrivateC2E + 0
00000024ab30 01d700000007 R_X86_64_JUMP_SLO 0000000000000000 _ZN14QObjectPrivateD2E + 0
320: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZN14QObjectPrivateC2Ei
326: 0000000000000000 0 OBJECT GLOBAL DEFAULT UND _ZTI14QObjectPrivate
471: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZN14QObjectPrivateD2Ev

~/dev/arora/build> readelf /usr/lib64/libQtSvg.so.4 -a | grep QObjectPrivate
000000250520 010f00000001 R_X86_64_64 0000000000000000 _ZN14QObjectPrivate15c + 0
000000250800 010f00000001 R_X86_64_64 0000000000000000 _ZN14QObjectPrivate15c + 0
000000250540 013900000001 R_X86_64_64 0000000000000000 _ZTI14QObjectPrivate + 0
000000250820 013900000001 R_X86_64_64 0000000000000000 _ZTI14QObjectPrivate + 0
000000251730 013300000007 R_X86_64_JUMP_SLO 0000000000000000 _ZN14QObjectPrivateC2E + 0
000000251ab0 01ca00000007 R_X86_64_JUMP_SLO 0000000000000000 _ZN14QObjectPrivateD2E + 0
271: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZN14QObjectPrivate15chec
307: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZN14QObjectPrivateC2Ei
313: 0000000000000000 0 OBJECT GLOBAL DEFAULT UND _ZTI14QObjectPrivate
458: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZN14QObjectPrivateD2Ev

~/dev/arora/build> readelf ~/opt/qtcreator-0.9.2-rc1/lib/libQtSvg.so.4 -a | grep QObjectPrivate
000000256230 014700000001 R_X86_64_64 0000000000000000 _ZTI14QObjectPrivate + 0
000000256510 014700000001 R_X86_64_64 0000000000000000 _ZTI14QObjectPrivate + 0
000000257680 014100000007 R_X86_64_JUMP_SLO 0000000000000000 _ZN14QObjectPrivateC2E + 0
000000257a70 01dc00000007 R_X86_64_JUMP_SLO 0000000000000000 _ZN14QObjectPrivateD2E + 0
321: 0000000000000000 376 FUNC GLOBAL DEFAULT UND _ZN14QObjectPrivateC2Ei
327: 0000000000000000 24 OBJECT GLOBAL DEFAULT UND _ZTI14QObjectPrivate
476: 0000000000000000 373 FUNC GLOBAL DEFAULT UND _ZN14QObjectPrivateD2Ev
1170: 0000000000000000 376 FUNC GLOBAL DEFAULT UND _ZN14QObjectPrivateC2Ei
1182: 0000000000000000 24 OBJECT GLOBAL DEFAULT UND _ZTI14QObjectPrivate
1371: 0000000000000000 373 FUNC GLOBAL DEFAULT UND _ZN14QObjectPrivateD2Ev

**pawelprazak** · 16th February 2009, 10:02

openSUSE's guys have just updated system Qt to 4.5.0-rc1 and the ploblem is gone

**wysota** · 16th February 2009, 21:46

It wouldn't work because your application would be using a different Qt library than the KDE the plugin is compiled against which would cause a name clash and the plugin wouldn't load.

**pawelprazak** · 16th February 2009, 21:59

Originally Posted by wysota

It wouldn't work because your application would be using a different Qt library than the KDE the plugin is compiled against which would cause a name clash and the plugin wouldn't load.

Theoretically, yes, practically, no, because it works with Qt Creator compiled with Qt 4.5-rc1, but now it's irrelevant due to openSUSE's KDE team move to Qt 4.5-rc1