Hi, Am Samstag, 11. Februar 2012, 20:00:01 schrieb Alexander Neundorf: > Hi, > 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. The perception that dbus is a problem on Windows is outdated. Dbus was a huge problem on windows but currently the situation is pretty good, we reall have no known issues with it. We can run multiple instances with different applications, it can do multiuser and it''s very stable and reliable for our platform.
I think dbus can and needs to stay. > > 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 ? Signed i really would love to get rid of it. > 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 ? Well kded handles some generic "kde" maintanence and watch stuff. For example it monitors if the windows registry entry for the timezone changes to notify kde applications. It also handles ssl certificate warnings and i think some more stuff. For a single application you could probably better handle all this in process. But the better approach would probably be to just use those parts of KDE if you need them. (Amarok probably does not care mutch about timezones ;) ) > > 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 ? In my personal opinion as one of the KDE-Windows guys, yes. On my windows desktop i am running three different KDE's (Kontact / Amarok okular and the other stuff / Gpg4win ) Ok I'm a developer but if we want to have nice packages of okular and amarok as standalone "Apps" this will happen more and more. And just reducing stuff to "what the app needs" will really help there. > 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. Agreed. > 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. Yes framework has great possibilties for us from a point of packaging single applications. But speaking for the Windows developers, splitting up kdelibs and the general frameworks effort will make life easier for us without it beeing platform specific. But I agree with you that we should try to get more involved with frameworks, we really don't have a strategy there or someone who we can point to as our "Frameworks guy" (Well when in doubt Patrick is always the guy for everything) ;) . There is definitly need for a discussion about "frameworks from a cross platform point of view" Regards, and thanks for starting this discussion Andre
