From kdelibs4 to KDE frameworks... how to make KDE more cross platform...
neundorf at kde.org
Sat Feb 11 19:00:01 GMT 2012
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
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.
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:
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
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
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
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.
More information about the kde-core-devel