From kdelibs4 to KDE frameworks... how to make KDE more cross platform...

[Alexander Neundorf]

Hi,

KDE is based on Qt, and Qt is very cross platform.
While there are Windows and also OSX builds of KDE4, they are not really 
successful.
I mean, it's not like everybody is running amarok today under Windows, or 
kate, or kdevelop, or digikam, kmail, etc.
Some applications decided to go Qt-only for their Windows versions, e.g. 
Marble.

At FOSDEM I talked with Pau, and he said one thing that scares Windows users 
are (beside the huge downloads tdue to the many dependencies) that running a 
KDE application needs several helper processes running:
1. DBUS 
2. kdeinit
3. klauncher
4. kded
5. kuiserver

So, can we cut down this number ?

Pau had the idea to write a fake libdbus for Windows, which internally doesn't 
talk to a dbus daemon, but which uses the Windows messaging service.
On Linux DBUS is no problem. On Mac ? I don't know. Probably better than under 
Windows.

kdeinit... can we make this optional ? It also sucks from the buildsystem POV.
I remember we discussed this at the Desktop Summit... Would we have the same 
gains if we would simply build executables which export symbols, and if 
kdeinit is there, it runs those executables by dlopening them and running that 
symbol ? Would that have the same effect as loading KLMs ?
Do I remember correctly that this is not (yet ?) supported on all 
distros/architectures ? Would that be a problem ? Or would this simply 
increase the pressure to add support for this everywhere ?

klauncher... this is quite central. I guess there is not much what could be 
done...

kded... for what things is this needed when running only a single application 
?

kuiserver... if there are out-of-process kioslaves, I guess then there has to 
be an out-of-process kuiserver.


Or, should we for Windows and OSX simply forget the KDE "desktop" and just 
concentrate on KDE applications ?
E.g. ignore that we save resources by centralizing and sharing stuff like 
kioslaves among multiple applications ? Try to do more things in-process, 
maybe in threads ?
It is cool to be able to replace the Windows shell... but does it make sense ? 
For applications it is IMO a feasible goal to be used by normal users under 
Windows, but replacing the Windows shell will stay only something for geeks I 
think.

To make it short, now that we are going towards KDE frameworks, we should make 
sure that if there is something we can do to improve our situation on non KDE 
desktops, especially on non-UNIX, we should do that now or at least make sure 
that necessary changes can be done later on during the KDE frameworks 
compatiblity period without breaking compatiblity.

Alex