Bug 267770

CCing dfaure because his krdb commit is triggering the regression.

Actually, kpackagekitsmarticon is already a KUniqueApplication (i.e. a KApplication subclass), yet we still end up with the theme not getting found.

KApplication doesn't set the plugin path, it expects it to be already set. It does try to set the default theme, but that doesn't help if Qt doesn't find it.

So there's no easy/good fix for this within KPackageKit, it needs to be fixed inside kdelibs (KApplication) or kde-workspace (krdb, by reverting the offending change).

Created attachment 57811 [details]
Screenshot of the "ugly" plain old QT style

I can confirm the behavior. I previously thought it was an ubuntu specific bug. Here
is its link : https://bugs.launchpad.net/ubuntu/+source/kpackagekit/+bug/707916.
In case it's not readable here is what I wrote :

I also have a similar issue with maverick and the latest upgrade to KDE SC 4.6.1 a few
days ago. Here is what I observed :

When there are new upgrades available, the notification icon shows
up and I click on it. Quite usual.

However, when the application windows is displayed, it does not
take my (default) theme into account. It's displayed with the old
QT windows-like style.

   Launching kpackagekit from the menus : everything ok
   Launching it from the command line : ok
   Launching it from the command line with sudo : same bad display
   Launching it from the command line with kdesudo : ok

Can we add something like this to KApplicationPrivate::init in kdeui/kernel/kapplication.cpp?

/* Ensure the KDE Qt plugins are found.
   QT_PLUGIN_PATH is not set in all situations. */
QStringList pluginPaths = KGlobal::dirs()->resourceDirs(QLatin1String("qtplugins"));

// reverse plugin paths because QCoreApplication::addLibraryPath prepends
QStringList pluginPathsReversed:
foreach(const QString &pluginPath, pluginPaths)
  pluginPathsReversed.prepend(pluginPath);

foreach(const QString &pluginPath, pluginPathsReversed) {
  // prevent duplicates
  QCoreApplication::removeLibraryPath(pluginPath);

  // add the path (to the front)
  QCoreApplication::addLibraryPath(pluginPath);
}

I think that should fix the issue for KPackageKit, and any other kdelibs-using stuff getting activated through D-Bus activation. (It won't help for Qt-only stuff getting activated through D-Bus activation though, if there's any of that.) And yes, looking at the Qt code, it should be safe to call those 2 static QCoreApplication methods before the QCoreApplication is constructed.

Created attachment 57852 [details]
kdelibs-4.6.1-kde#267770.patch

This is the proposed patch we are now testing in Fedora. Compared to my previous proof-of-concept snippet, I fixed:
* a typo (':' instead of ';') which made the code fail to compile,
* incorrect use of QLatin1String for a method which expects a const char *,
* minor coding style nitpicks (but the coding style might still need tweaks, especially because the surrounding code has very inconsistent styles).

So we tested the patch, it doesn't work. :-( It has no visible effect.
Either more fixes or a different fix are needed.

So the reason this idea doesn't work is that KApplicationPrivate::init runs too late, only after QApplication is already fully initialized. (Grrr, I should have thought of that.)

One possible solution, though a bit hackish, would be to stuff the plugin code into KCmdLineArgs::init. That runs before QApplication::QApplication. But is it really where initialization code is supposed to sit?

Git commit 979a19afe93d1e4a5be684c1139b6ab242e6b9b6 by David Faure.
Committed on 11/03/2011 at 21:01.
Pushed by dfaure into branch 'KDE/4.6'.

Add paths to qt plugins (from kstandarddirs) before qapp is created.

Necessary for apps started through d-bus activation, so that the kde widget
style is loaded. The QCoreApp::instance test was "so that qt.conf is read" (db852684)
but the whole idea of 9d7eb8f7 is that this doesn't rely on the qt config files anymore.

FIXED-IN: 4.6.2
BUG: 267770

M  +1    -1    kdecore/kernel/kcomponentdata.cpp     
M  +2    -0    kdeui/kernel/kapplication.cpp     

http://commits.kde.org/kdelibs/979a19afe93d1e4a5be684c1139b6ab242e6b9b6

Git commit f1a81feb7851ceaf91d5bfe3ebdafb5f1052260a by David Faure.
Committed on 11/03/2011 at 21:01.
Pushed by dfaure into branch 'master'.

Add paths to qt plugins (from kstandarddirs) before qapp is created.

Necessary for apps started through d-bus activation, so that the kde widget
style is loaded. The QCoreApp::instance test was "so that qt.conf is read" (db852684)
but the whole idea of 9d7eb8f7 is that this doesn't rely on the qt config files anymore.

FIXED-IN: 4.6.2
BUG: 267770
(cherry picked from commit 979a19afe93d1e4a5be684c1139b6ab242e6b9b6)

M  +1    -1    kdecore/kernel/kcomponentdata.cpp     
M  +2    -0    kdeui/kernel/kapplication.cpp     

http://commits.kde.org/kdelibs/f1a81feb7851ceaf91d5bfe3ebdafb5f1052260a

This doesn't fix it for me. I'm using kdelibs ata8cf52fa332293455a4a90080931e986ffc8c588 (which includes David's fix) but the telepathy-kde chat handler started is still using the wrong theme.

I've noticed that a bunch of env. variables isn't set for the dbus-launched apps, among them KDE_FULL_SESSION.
Unsetting this variable in a shell session will result in equally unthemed KDE apps.

The fix will only work for a KApplication. If your chat handler is a QApplication, you'll have to fix it to be a KApplication.

It's a subclass of KApplication, so I think this should work.

*** Bug 268193 has been marked as a duplicate of this bug. ***

The issue doesn't seem to be fixed yet. We are experiencing it with the telepathy chat handler again (see Bug #269861 ).

I noticed that the problem only occurs when the environment of the process doesn't contain KDE_FULL_SESSION="true".
In startkde, that environment variable is only set *after* dbus is started, so consequently any app that is started by dbus will inherit it's environment and thus *not* have that env variable set.
I don't think we can rely on that env var being set before dbus is started, so any modification is startkde would only be a hack.

I think Arno's claim is true. The only way for KDE applications to know that they run in a KDE environment is the KDE_FULL_SESSION environment variable, and since this is not set, it is reasonable (and correct) for them to be themed differently. If we hack KApplication so that it always loads the KDE style even if KDE_FULL_SESSION is not set, then we will get KDE themed apps on gnome or other environments (windows, osX...), which is not desirable.

I think the correct solution is to change startkde so that KDE_FULL_SESSION is set before dbus-daemon is started.

This seems to be fixed for me.