Qt KDE integration in kdereview.

[Olivier Goffart]

Hello.

I have just submitted a new plugin in kdereview:  qguiplatformplugin_kde

The objective of this plugin is to allow pure Qt Application (not KDE ones) to
get better integration into KDE.


Qt tries already to make KDE (and GNOME) as much as it can. For instance, we
try to guess the KDE style and the
KDE palette from the KDE config files.   This however not 100% reliable: For
instance, we do not know the location of KDEHOME (when $KDEHOME is not set).
Is it ~/.kde or ~/.kde4 or other? We use QSettings to parse the KDE config file
(which does not understand every KDE tricks)

To get the Gtk+ integration Qt dynamically link against Gtk+ itself.  It
cannot do that with KDE because kdelbis are in C++ (name mangling)
and they depends on Qt (circular dependence)

So the only way to go is to introduce hook inside Qt that KDE would use.
And there it is:  the QGuiPlatformPlugin.
It is a kind of private hooks inside Qt to get KDE integration (and in the
future any platform based on KDE such as the future Maemo)

Qt will load the Kde plugin if the Qt application is running on KDE

The Plugin currently provides:
  * Reading the KDE style name from the config
  * Reading the KDE palette from The KDE config
  * Finding the right icon them for QIcon::fromTheme
  * Some Options such as the toolbar icon size, or the single/double click
options
  * Finding the icon for a given file (for the QFileSystemModel)
  * KFileDialog as native backend for a QFileDialog (without the need of using
the static function, just like in mac or windows)
  * KColorDialog for the QColorDialog

The plugin should go either in kdeextragear, or kdebase/runtime whatever is
the most appropriate.
(kdebase/runtime would ease the release,  but it is more related to the
version of Qt than the version of KDE)

I am also open to any suggestions of others things the plugin should provide
(for Qt 4.7)

Comments?


--
Olivier

[Lubos Lunak]

On Tuesday 03 of November 2009, Olivier Goffart wrote:
> Qt will load the Kde plugin if the Qt application is running on KDE
>
> The Plugin currently provides:
>   * Reading the KDE style name from the config
>   * Reading the KDE palette from The KDE config
>   * Finding the right icon them for QIcon::fromTheme
>   * Some Options such as the toolbar icon size, or the single/double click
> options

 Wouldn't it be better to just go with XSETTINGS[*] for (some of) these? It
would save special-casing them for each X11 desktop and would also solve the
problem of running some app as a different user or remotely (at least, that's
the theory, having a better look at XSETTINGS is somewhere in my
TODO-when-I-have-too-much-time).

[*]http://standards.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html

>   * Finding the icon for a given file (for the QFileSystemModel)
>   * KFileDialog as native backend for a QFileDialog (without the need of
> using the static function, just like in mac or windows)
>   * KColorDialog for the QColorDialog
>
> The plugin should go either in kdeextragear, or kdebase/runtime whatever is
> the most appropriate.
> (kdebase/runtime would ease the release,  but it is more related to the
> version of Qt than the version of KDE)
>
> I am also open to any suggestions of others things the plugin should
> provide (for Qt 4.7)

 You could probably short-circuit some of the stuff in QDesktopServices
directly to the KDE calls instead of all the black magic there.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http://www.suse.cz

On Tuesday 03 November 2009 17:55:51 Olivier Goffart wrote:
> Hello.
>
> I have just submitted a new plugin in kdereview:  qguiplatformplugin_kde
>
> The objective of this plugin is to allow pure Qt Application (not KDE ones)
>  to get better integration into KDE.
How about integrating KDE widgets directly into pure Qt applications?

I see that QMainWindow::menuBar(), QMainWindow::statusBar() and
QMainWindow::addToolBar(QString) can be hacked. Maybe that plugin can provide
the menu/statusbar/toolbar "virtual constructors" or something.

I assume this might break some Qt applications in very splendid ways, but it's
an interesting ideas to test.

On Tuesday 03 November 2009, Diego Iastrubni wrote:

> On Tuesday 03 November 2009 17:55:51 Olivier Goffart wrote:
> > Hello.
> >
> > I have just submitted a new plugin in kdereview:  qguiplatformplugin_kde
> >
> > The objective of this plugin is to allow pure Qt Application (not KDE
> > ones) to get better integration into KDE.
>
> How about integrating KDE widgets directly into pure Qt applications?
>
> I see that QMainWindow::menuBar(), QMainWindow::statusBar() and
> QMainWindow::addToolBar(QString) can be hacked. Maybe that plugin can
>  provide the menu/statusbar/toolbar "virtual constructors" or something.

You mean in order to create KMainWindows and KToolBars?
What would this provide to the Qt applications?
AFAICS we mostly have these for additional features, which those Qt-only apps
wouldn't use, like handling of settings (window size and toolbar positions),
movable toolbars (off by default), a more elaborate logic for finding out when
to exit the process (urgh, would lead to surprises in those Qt only apps),
etc. I think Qt-only apps would look exactly the same with just
s/QMainWindow/KMainWindow/...

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

On Tuesday, 2009-11-03, Olivier Goffart wrote:

> Hello.
>
> I have just submitted a new plugin in kdereview:  qguiplatformplugin_kde
>
> The objective of this plugin is to allow pure Qt Application (not KDE ones)
>  to get better integration into KDE.
>
>
> Qt tries already to make KDE (and GNOME) as much as it can. For instance,
>  we try to guess the KDE style and the
> KDE palette from the KDE config files.   This however not 100% reliable:
>  For instance, we do not know the location of KDEHOME (when $KDEHOME is not
>  set). Is it ~/.kde or ~/.kde4 or other? We use QSettings to parse the KDE
>  config file (which does not understand every KDE tricks)

KDEHOME is easy: $HOME/.kde is not set
http://techbase.kde.org/KDE_System_Administration/Environment_Variables#KDEHOME

> To get the Gtk+ integration Qt dynamically link against Gtk+ itself.  It
> cannot do that with KDE because kdelbis are in C++ (name mangling)
> and they depends on Qt (circular dependence)

Couldn't we provide an external "C" function in kdelibs which returns an
object of whatever class you use for getting the platform stuff.

> The plugin should go either in kdeextragear, or kdebase/runtime whatever is
> the most appropriate.
> (kdebase/runtime would ease the release,  but it is more related to the
> version of Qt than the version of KDE)

workspace would have been my guess

> I am also open to any suggestions of others things the plugin should
>  provide (for Qt 4.7)

A QNetworkAccessManager using KIO?
KDE Cookie and Proxy Handling?

Cheers,
Kevin

--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

[Olivier Goffart]

Le Tuesday 03 November 2009, Lubos Lunak a écrit :

> On Tuesday 03 of November 2009, Olivier Goffart wrote:
> > Qt will load the Kde plugin if the Qt application is running on KDE
> >
> > The Plugin currently provides:
> >   * Reading the KDE style name from the config
> >   * Reading the KDE palette from The KDE config
> >   * Finding the right icon them for QIcon::fromTheme
> >   * Some Options such as the toolbar icon size, or the single/double
> > click options
>
>  Wouldn't it be better to just go with XSETTINGS[*] for (some of) these? It
> would save special-casing them for each X11 desktop and would also solve
>  the problem of running some app as a different user or remotely (at least,
>  that's the theory, having a better look at XSETTINGS is somewhere in my
> TODO-when-I-have-too-much-time).
>
> [*]http://standards.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html

XSETTINGS could be used for the icon theme.  but It's not used in practice,
and Qt just follow the practice.  And even if it was, we would still need to
use the same mechanism as KDE for 100% reliability.

Qt use XSettings (or similar) for the palette. But it doesn't work well as
both gtk and kde have more colors in their palette than what is exposed
thought the x settings.

>  You could probably short-circuit some of the stuff in QDesktopServices
> directly to the KDE calls instead of all the black magic there.

xdg-open is used.  This is not black magic
(But this is a good point that it could be short-circuited)

On Tuesday 03 November 2009, Kevin Krammer wrote:
> > To get the Gtk+ integration Qt dynamically link against Gtk+ itself.  It
> > cannot do that with KDE because kdelbis are in C++ (name mangling)
> > and they depends on Qt (circular dependence)
>
> Couldn't we provide an external "C" function in kdelibs which returns an
> object of whatever class you use for getting the platform stuff.
>
Shouldn't be necessary, name-mangling is deterministic and well-defined. I am
also not sure how the circular dependency would be a problem. The existing Qt
plugins also depend on Qt libraries, these are resolved when linked to the
already loaded library (the one loading them).

But while doing the same as Gtk+ is doable, the proposed solution still looks
cleaner.

`Allan

[Olivier Goffart]

Le Tuesday 03 November 2009, Kevin Krammer a écrit :

> On Tuesday, 2009-11-03, Olivier Goffart wrote:
> > Hello.
> >
> > I have just submitted a new plugin in kdereview:  qguiplatformplugin_kde
> >
> > The objective of this plugin is to allow pure Qt Application (not KDE
> > ones) to get better integration into KDE.
> >
> >
> > Qt tries already to make KDE (and GNOME) as much as it can. For instance,
> >  we try to guess the KDE style and the
> > KDE palette from the KDE config files.   This however not 100% reliable:
> >  For instance, we do not know the location of KDEHOME (when $KDEHOME is
> > not set). Is it ~/.kde or ~/.kde4 or other? We use QSettings to parse the
> > KDE config file (which does not understand every KDE tricks)
>
> KDEHOME is easy: $HOME/.kde is not set
> http://techbase.kde.org/KDE_System_Administration/Environment_Variables#KDE
> HOME

No.  Some distribs change the default to .kde4 (there is a cmake flag to
change it, and it can be set to anything)

> > To get the Gtk+ integration Qt dynamically link against Gtk+ itself.  It
> > cannot do that with KDE because kdelbis are in C++ (name mangling)
> > and they depends on Qt (circular dependence)
>
> Couldn't we provide an external "C" function in kdelibs which returns an
> object of whatever class you use for getting the platform stuff.

We tought about that.
But we will need the same stuff in other platform (maemo, ...)

> > The plugin should go either in kdeextragear, or kdebase/runtime whatever
> > is the most appropriate.
> > (kdebase/runtime would ease the release,  but it is more related to the
> > version of Qt than the version of KDE)
>
> workspace would have been my guess

Now that i think about it, workplace is probably better than runtime.

> > I am also open to any suggestions of others things the plugin should
> >  provide (for Qt 4.7)
>
> A QNetworkAccessManager using KIO?
> KDE Cookie and Proxy Handling?

Yes, some of this is in the roadmap.

On Tuesday, 2009-11-03, Olivier Goffart wrote:
> Le Tuesday 03 November 2009, Kevin Krammer a écrit :
> > On Tuesday, 2009-11-03, Olivier Goffart wrote:

> > > Qt tries already to make KDE (and GNOME) as much as it can. For
> > > instance, we try to guess the KDE style and the
> > > KDE palette from the KDE config files.   This however not 100%
> > > reliable: For instance, we do not know the location of KDEHOME (when
> > > $KDEHOME is not set). Is it ~/.kde or ~/.kde4 or other? We use
> > > QSettings to parse the KDE config file (which does not understand every
> > > KDE tricks)
> >
> > KDEHOME is easy: $HOME/.kde is not set
> > http://techbase.kde.org/KDE_System_Administration/Environment_Variables#K
> >DE HOME
>
> No.  Some distribs change the default to .kde4 (there is a cmake flag to
> change it, and it can be set to anything)

You mean they change the default but forget to apply the same change to Qt?

Maybe startkde could set KDEHOME to localprefix if it is not set yet?

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

On Tuesday 03 November 2009 16:30:43 Olivier Goffart wrote:
[snipped]
> > > I am also open to any suggestions of others things the plugin should
> > >  provide (for Qt 4.7)
> >
> > A QNetworkAccessManager using KIO?
> > KDE Cookie and Proxy Handling?
>
> Yes, some of this is in the roadmap.

That KIO and cookiejar integration has already been done. See
KIO::Integration::AccessManager and KIO::Integration::CookieJar in
kio/kio/accessmanager.{h|cpp} in trunk. Actually KIO::AccessManager has been
in existence since KDE 4.1

[Albert Astals Cid-2]

A Dimarts, 3 de novembre de 2009, Olivier Goffart va escriure:

> Hello.
>
> I have just submitted a new plugin in kdereview:  qguiplatformplugin_kde
>
> The objective of this plugin is to allow pure Qt Application (not KDE ones)
>  to get better integration into KDE.
>
>
> Qt tries already to make KDE (and GNOME) as much as it can. For instance,
>  we try to guess the KDE style and the
> KDE palette from the KDE config files.   This however not 100% reliable:
>  For instance, we do not know the location of KDEHOME (when $KDEHOME is not
>  set). Is it ~/.kde or ~/.kde4 or other? We use QSettings to parse the KDE
>  config file (which does not understand every KDE tricks)
>
> To get the Gtk+ integration Qt dynamically link against Gtk+ itself.  It
> cannot do that with KDE because kdelbis are in C++ (name mangling)
> and they depends on Qt (circular dependence)
>
> So the only way to go is to introduce hook inside Qt that KDE would use.
> And there it is:  the QGuiPlatformPlugin.
> It is a kind of private hooks inside Qt to get KDE integration (and in the
> future any platform based on KDE such as the future Maemo)
>
> Qt will load the Kde plugin if the Qt application is running on KDE
>
> The Plugin currently provides:
>   * Reading the KDE style name from the config
>   * Reading the KDE palette from The KDE config
>   * Finding the right icon them for QIcon::fromTheme
>   * Some Options such as the toolbar icon size, or the single/double click
> options
>   * Finding the icon for a given file (for the QFileSystemModel)
>   * KFileDialog as native backend for a QFileDialog (without the need of
>  using the static function, just like in mac or windows)
>   * KColorDialog for the QColorDialog
>
> The plugin should go either in kdeextragear, or kdebase/runtime whatever is
> the most appropriate.
> (kdebase/runtime would ease the release,  but it is more related to the
> version of Qt than the version of KDE)
>
> I am also open to any suggestions of others things the plugin should
>  provide (for Qt 4.7)
>
> Comments?
>

The license says the file belongs to Nokia while it includes code taken from
kfiledialog.cpp

The list variable in qt2KdeFilter and kde2QtFilter should be declared const so
the real const begin() and end() are called on it otherwise will probably fail
to compile when specifying strict iterators.

One question, how does it decide if it should use the KDE integration or the
GTK one?

It's nice that Nokia cares about KDE :-)

Albert

On Tuesday 03 November 2009 17:10:19 Kevin Krammer wrote:

> On Tuesday, 2009-11-03, Olivier Goffart wrote:
> > Le Tuesday 03 November 2009, Kevin Krammer a écrit :
> > > On Tuesday, 2009-11-03, Olivier Goffart wrote:
> > > > Qt tries already to make KDE (and GNOME) as much as it can. For
> > > > instance, we try to guess the KDE style and the
> > > > KDE palette from the KDE config files.   This however not 100%
> > > > reliable: For instance, we do not know the location of KDEHOME (when
> > > > $KDEHOME is not set). Is it ~/.kde or ~/.kde4 or other? We use
> > > > QSettings to parse the KDE config file (which does not understand
> > > > every KDE tricks)
> > >
> > > KDEHOME is easy: $HOME/.kde is not set
> > > http://techbase.kde.org/KDE_System_Administration/Environment_Variables
> > >#K DE HOME
> >
> > No.  Some distribs change the default to .kde4 (there is a cmake flag to
> > change it, and it can be set to anything)
>
> You mean they change the default but forget to apply the same change to Qt?

You act like you're surprised. ;)

Besides, the end user can just as well toggle that switch as the packager if
they build from source (and that's not the entire point of Olivier's patch
anyways).

> Maybe startkde could set KDEHOME to localprefix if it is not set yet?

That wouldn't be a bad idea either, it's easier just to always have KDEHOME
set than special-casing it.

Regards,
 - Michael Pyne

On Wednesday 04 November 2009, Michael Pyne wrote:
> On Tuesday 03 November 2009 17:10:19 Kevin Krammer wrote:
> > Maybe startkde could set KDEHOME to localprefix if it is not set yet?
>
> That wouldn't be a bad idea either, it's easier just to always have KDEHOME
> set than special-casing it.

Yep, excellent idea.

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

On Wednesday 04 November 2009, Dawit A. wrote:
> On Tuesday 03 November 2009 16:30:43 Olivier Goffart wrote:
> [snipped]
>
> > > > I am also open to any suggestions of others things the plugin
should

> > > >  provide (for Qt 4.7)
> > >
> > > A QNetworkAccessManager using KIO?
> > > KDE Cookie and Proxy Handling?
> >
> > Yes, some of this is in the roadmap.
>
> That KIO and cookiejar integration has already been done. See
> KIO::Integration::AccessManager and KIO::Integration::CookieJar in
> kio/kio/accessmanager.{h|cpp} in trunk. Actually KIO::AccessManager

has
>  been in existence since KDE 4.1

Yes, that's great, but they're not used automatically by Qt-only apps;
that's what this thread is about ;)

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror
(http://www.konqueror.org).

[Olivier Goffart]

Le Wednesday 04 November 2009, Albert Astals Cid a écrit :
> The license says the file belongs to Nokia while it includes code taken
>  from kfiledialog.cpp

Right, i'll see what i need to do for the licence.

> The list variable in qt2KdeFilter and kde2QtFilter should be declared const

Fixed.

>  so the real const begin() and end() are called on it otherwise will
>  probably fail to compile when specifying strict iterators.

Explicit conversion is allowed.   Comparison and implicit conversion doesn't
work when working with strict iterators.


> One question, how does it decide if it should use the KDE integration or
>  the GTK one?

We have some heuristics based on the running window manager, and the
$DESKTOP_SESSION environement variable, and some X atoms.

Basicly, Qt detect KDE if KWin is the window manager, or $DESKTOP_SESSION ==
kde or kde4

There is more magic.  the code is in qt_init() function in
qapplication_x11.cpp

This is not perfect but seems to work.


> It's nice that Nokia cares about KDE :-)
>
> Albert
>

[George Kiagiadakis]

On Wed, Nov 4, 2009 at 3:19 AM, David Faure <faure@...> wrote:
> On Wednesday 04 November 2009, Michael Pyne wrote:
>> On Tuesday 03 November 2009 17:10:19 Kevin Krammer wrote:
>> > Maybe startkde could set KDEHOME to localprefix if it is not set yet?
>>
>> That wouldn't be a bad idea either, it's easier just to always have KDEHOME
>> set than special-casing it.
>
> Yep, excellent idea.

No, bad idea. If you are using both kde3 and kde4 apps and you want
them to use different KDEHOMEs, setting KDEHOME in startkde is just
going to force them both to use the same KDEHOME, which is not what we
want. That's why the KDE4_DEFAULT_HOME cmake variable exists.

On Wednesday, 2009-11-04, Michael Pyne wrote:

> On Tuesday 03 November 2009 17:10:19 Kevin Krammer wrote:
> > On Tuesday, 2009-11-03, Olivier Goffart wrote:
> > > Le Tuesday 03 November 2009, Kevin Krammer a écrit :
> > > > On Tuesday, 2009-11-03, Olivier Goffart wrote:
> > > > > Qt tries already to make KDE (and GNOME) as much as it can. For
> > > > > instance, we try to guess the KDE style and the
> > > > > KDE palette from the KDE config files.   This however not 100%
> > > > > reliable: For instance, we do not know the location of KDEHOME
> > > > > (when $KDEHOME is not set). Is it ~/.kde or ~/.kde4 or other? We
> > > > > use QSettings to parse the KDE config file (which does not
> > > > > understand every KDE tricks)
> > > >
> > > > KDEHOME is easy: $HOME/.kde is not set
> > > > http://techbase.kde.org/KDE_System_Administration/Environment_Variabl
> > > >es #K DE HOME
> > >
> > > No.  Some distribs change the default to .kde4 (there is a cmake flag
> > > to change it, and it can be set to anything)
> >
> > You mean they change the default but forget to apply the same change to
> > Qt?
>
> You act like you're surprised. ;)

Well, actually I am.
I didn't know about this cmake parameter so I thought it was one of those
unfortunate but necessary downstream modifications.
In which case they obviously would have to modify every other occurance of the
default as well.

This cmake parameter makes the documentation wrong or at least not precise
enough, which is really a pity.
Variables that can be unset or empty should have specified defaults so third
parties implementing their own code can rely on that.

Has this always been overridable this way or is this a recent (KDE4) addition?

> Besides, the end user can just as well toggle that switch as the packager
>  if they build from source (and that's not the entire point of Olivier's
>  patch anyways).

True. Lettings KDE handle these things is definitely better.
Will avoid problems like the current heuristics in Qt which mistakenly prefer
.kde4 over .kde instead of the other way around (preferring canonical default
over one potential override).

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

On Wednesday 04 November 2009, George Kiagiadakis wrote:

> On Wed, Nov 4, 2009 at 3:19 AM, David Faure <faure@...> wrote:
> > On Wednesday 04 November 2009, Michael Pyne wrote:
> >> On Tuesday 03 November 2009 17:10:19 Kevin Krammer wrote:
> >> > Maybe startkde could set KDEHOME to localprefix if it is not set yet?
> >>
> >> That wouldn't be a bad idea either, it's easier just to always have
> >> KDEHOME set than special-casing it.
> >
> > Yep, excellent idea.
>
> No, bad idea. If you are using both kde3 and kde4 apps and you want
> them to use different KDEHOMEs, setting KDEHOME in startkde is just
> going to force them both to use the same KDEHOME, which is not what we
> want.

True.
And I just realized that it wouldn't help making sure KDEHOME is always set,
since one can also run kde apps outside of a kde workspace (-> no startkde
run).

> That's why the KDE4_DEFAULT_HOME cmake variable exists.

Yeah but that's not introspectable.
Hmm, actually, it is:  `kde4-config --localprefix`, but calling a process
probably too slow for doing from Qt?

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Lubos Lunak]

On Wednesday 04 of November 2009, Olivier Goffart wrote:

> Le Wednesday 04 November 2009, Albert Astals Cid a écrit :
> > One question, how does it decide if it should use the KDE integration or
> >  the GTK one?
>
> We have some heuristics based on the running window manager, and the
> $DESKTOP_SESSION environement variable, and some X atoms.
>
> Basicly, Qt detect KDE if KWin is the window manager, or $DESKTOP_SESSION
> == kde or kde4
>
> There is more magic.  the code is in qt_init() function in
> qapplication_x11.cpp
>
> This is not perfect but seems to work.

 Gee. Please have a look at KDE_FULL_SESSION in startkde. Any good idea where
to put that information so that people don't always try to go to great
lengths to do it in a complicated and partially broken way when it's just
trivial (as long as one doesn't care about pretty old KDE versions)? This is
getting really boring.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http://www.suse.cz

[Olivier Goffart]

Le Wednesday 04 November 2009, Kevin Krammer a écrit :
> This cmake parameter makes the documentation wrong or at least not precise
> enough, which is really a pity.
> Variables that can be unset or empty should have specified defaults so
>  third parties implementing their own code can rely on that.
>
> Has this always been overridable this way or is this a recent (KDE4)
>  addition?

I think it is new since KDE4 but i might be wrong.

>
> > Besides, the end user can just as well toggle that switch as the packager
> >  if they build from source (and that's not the entire point of Olivier's
> >  patch anyways).
>
> True. Lettings KDE handle these things is definitely better.
> Will avoid problems like the current heuristics in Qt which mistakenly
>  prefer .kde4 over .kde instead of the other way around (preferring
>  canonical default over one potential override).

The thing is: in practice, many distribution had .kde4 for kde4 and .kde for
kde3 applications.
When we detect we are running in a kde4 desktop (again heuristics), we prefer
.kde4 if it exists.

Now, we had the case of people that had a .kde4 in their /home because they
tested development version at some point, and now use the distro package that
uses .kde, and Qt get it wrong.


As  David suggested, there is the `kde4-config --localprefix`,  but this would
have slow down every application startup just of that.  (One can argue that
loading a plugin also slows down the startup, but it should still be much
faster, and provides more stuff)

--
Olivier