Qt KDE integration in kdereview.

[George Kiagiadakis]

On Wed, Nov 4, 2009 at 10:59 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Wednesday 04 November 2009, David Faure wrote:
>> On Wednesday 04 November 2009, George Kiagiadakis wrote:
>> > On Wed, Nov 4, 2009 at 3:19 AM, David Faure <faure at kde.org> 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?
>
> Hmm, if it's done once on application startup it might be acceptable.
>
> It's also saved in share/apps/cmake/modules/KDELibsDependencies.cmake, in the
> KDE_DEFAULT_HOME variable.
> You can basically rely on the format of that line:
> set(KDE_DEFAULT_HOME ".kde")
> So without really parsing it just matching a regexp should do.

But that would make Qt depend on the kde cmake files, which are
usually shipped in separate development packages, not together with
kdelibs...

I think that getting the information from libkdecore itself is the
right thing to do, so the platform plugin makes sense. Everything else
is just hacks...