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 _______________________________________________ Kde-frameworks-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
