Minimal kdelibs on embedded platforms

Ralf Habacker ralf.habacker at freenet.de
Tue Dec 1 23:46:48 GMT 2009


Pau Garcia i Quiles schrieb:
> On Tue, Dec 1, 2009 at 5:13 PM, Lubos Lunak <l.lunak at suse.cz> wrote:
>   
>> On Tuesday 01 of December 2009, Pau Garcia i Quiles wrote:
>>     
>>>> Second, KDE libraries often need KDE services running and/or installed.
>>>> That is, kdebase/runtime, plus kdeinit, klauncher, kded, kglobalaccel,
>>>> etc.
>>>>         
>>> With my commercial software developer hat on, I must say that those,
>>> and DBus, are the only things preventing us from adopting KDElibs and
>>> KOfficeLibs for Windows software development: lots of processes
>>> spawned, maybe conflicting versions of Qt (Qt with DBus vs Qt without
>>> DBus, for instance), etc
>>>       
>>  Unless all you want to hear is "oh, so sad", I think you should also put on
>> your KDE developer hat and say what you suggest as the fix. Are we to
>> redesign kdelibs just because Windows has some serious deficiencies?
>>     
>
> The same problems are present on Mac, I must say. We still do not
> develop for Mac but I'd say we'll do in a year.
>
> I do not know kdelibs to the point that I could say if it's feasible
> to have kdelibs working on Windows and Mac without DBus, 
may be solvable by a dummy QDbus implementation or build system options 
to exclude qdbus stuff from build ?

http://lxr.kde.org/ident?i=QDBusConnection gives a good overview which 
areas are affected

> kded,
>   
need to be analysed in which area kdelibs will not work without
> kdeinit, 
only a wrapper -. started internal in kdelibs (KToolInvocation) - adding 
a cmake options would solve this in minutes.

> etc. I'd say it requires so much work it's unrealistic to
> propose that before KDE5, if at all.
>   
I guess this depends on the related application requirements.

Ralf







More information about the kde-core-devel mailing list