Open kachelaqa opened 10 years ago
If setting those environment variables makes a difference I think it is Qt5 itself that pick up those settings and not qtcurve. In that case, I find it a little bit funny to explicitly impliment such logic just for Qt5.
But setting those environment variables doesn't make a difference with Qt4. So why should it do so for Qt5?
I have just checked qt5 source code and they are indeed parsing the KDE4 palette if they think KDE4 is used.
For qt4, it will be either qt4 always respect kde4 settings or you are using qtcurve-kde4.
I agree with you that consistency is important but I don't think this behavior is a bug in qtcurve-qt5. I would prefer this to be fixed in the qtcurve common libraries rather than adding some random logic in qtcurve-qt5. (However, I'm afraid it is not going to happen very soon since I am very busy with personal problem this year...=( )
It doesn't seem to make a difference whether qtcurve-kde4 or qtcurve-qt4 is used. They both manage to pick up the KDE settings. I have checked a few other styles with Qt4, and they all pick up the KDE settings (except for the gtk+ style, of course). So I agree that it does not seem to be a qtcurve-specific issue.
I suppose this is all a side-effect of Qt's frankly brain-dead decision to get rid of the Trolltech.conf
file without providing anything to replace it. For people who don't have a mainstream DE setup, this really, really sucks badly.
Looking through the source code for qtcurve, I see a lot of QTC_QT5_ENABLE_KDE
sections. I assume that this is switched on by default, but what would be the consequences of switching it off? (Yeah, I know I can just compile it and see, but that won't necessarily make it obvious what changes are involved).
No that option is not switched on by default and I don't think it can compile if you swith it on.
It is the same option for qt4 to link to kdelibs and it is supposed to link qtcurve-qt5 to kdelibs (of kf5) when switching it on. Since I have not got such a environment to test, that option is off and is not doing anything.
And I guess what happens in qt5 is that they create this qpa and hand everything over to the plugin for the underlaying system (DE for example) and no one have ever bother writing one that uses a simple configure file .....
Ah, so in fact it's maybe because QTC_QT5_ENABLE_KDE
isn't switched on that I'm seeing the differences in behaviour.
I think I looked at the Qt Platform Abstraction stuff previously, but there was virtually no documentation available for it at the time. It looks like that may have improved a little bit now, so I might have a look at it all again. I think my lack of C++ programming skills is going to prevent me making any progress with it, though...
I don't think enable kdelibs in qt5 will solve the problem, because it should read the setting of kde5 rather than kde4...
Yes, perhaps I should have said some of the differences - I assume that there is a lot more involved than just reading the settings themselves.
It looks like my only real options at the moment boil down to either finding a way to work with a fake KDE desktop, or creating an appropriate platform plugin.
When using qtcurve with Qt4, it will pick up the settings for things like colours, fonts, etc from the KDE settings. And it does this despite the fact that I am not using a specific DE (I just use a plain openbox desktop).
However, I am finding that this does not work for me with Qt5, unless I fake a KDE desktop by setting the
KDE_FULL_SESSION
andKDE_SESSION_VERSION
variables. Is there a way to force qtcurve to always read the KDE settings with Qt5 like it does with Qt4?