[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Qt KDE integration in kdereview.
From:       George Kiagiadakis <kiagiadakis.george () gmail ! com>
Date:       2009-11-04 22:50:13
Message-ID: ba4a6e220911041450k1f980d5cidd9cd558c3760eeb () mail ! gmail ! com
[Download RAW message or body]

On Wed, Nov 4, 2009 at 10:59 PM, Alexander Neundorf <neundorf@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@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...

[prev in list] [next in list] [prev in thread] [next in thread]