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