kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
thiago at kde.org
Sat Aug 20 11:20:55 BST 2011
On Saturday, 20 de August de 2011 10:02:31 Oswald Buddenhagen wrote:
> On Tue, Aug 16, 2011 at 08:58:02PM +0200, Thiago Macieira wrote:
> > frameworks (qt-based), applications and workspace, that sounds pretty much
> > what the KDE Platform is. What are you excluding in your definition?
> > kded, klauncher, kdeinit, kglobalaccel, kwallet?
> yes, among other things.
> kded's module activation is redundant with systemd.
But not at all the same impact. Starting an application and negotiating its
connection to D-Bus is hardly comparable to loading a plugin in a daemon that
is already connected.
> as it happens, lennart also made a mini-daemon dealing with host name
> changes, which is another thing kded does.
> klauncher is conceptually redundant with systemd as well. the backend it
> uses is kdeinit, which *should* be in systemd - it's not like it would
> not benefit gnome as well (otherwise there would be no maemo booster) -
> we just need some fresh numbers to justify the hack, and some arguments
> why the hack isn't *that* bad after all.
That I agree: klauncher is systemd for KDE only, so we should see about
getting the same benefits from systemd instead.
There are two drawbacks with that, though:
1) systemd will not likely ever run on non-Linux systems, not even the BSDs.
Lennart simply isn't interested on ensuring compatibility and might even
reject patches which introduce differences to Linux-specific behaviour.
2) Lennart is also very much opposed to the fork-no-exec solution that kdeinit
and booster use to pre-initialise. Prelinking, as we've discussed, is only a
partial solution. This is something that requires rethinking everything and
will involve a lot of fixing in all libraries.
> kwallet is already in the process of being replaced by a cross-desktop
> specification. i don't see why the backend needs to be desktop-specific,
> but i guess a monolithic implementation is easier, both technically and
> on a collaboration level.
A cross-desktop specification, but we still use kwallet. There's no reason to
dump it in favour of another implementation. So I see no arguments at all in
favour of dropping it -- in fact, I see more in keeping it.
> kglobalaccel would sorely need a cross-desktop solution on the backend
> side, too.
It needs a global spec too, since global shortcut grabbing with X11 libs only
is sorely lacking. I think the solution we made for KDE 4 is actually quite
good. Anyone wants to create an XDG spec for global accelerators?
But just as before, I don't see why our code can't be cross-desktop. So no
argument in favour of dropping kglobalaccel.
> but it gets more interesting. just look into systemsettings and see how
> many things are kde-specific while they should be global, often even
> below the desktop level.
> most of this doesn't need shared code; it could be covered by shared
> specification. but to do this, there needs to be a powerful shared
> configuration storage. dconf anyone?
Yes. If you profile with massif any KDE application's startup, you see it
consumes a lot of memory in KConfig and the QHashes it keeps. And remember that
kDebug uses KConfig.
So during the Summit I began thinking of a way to use memory-mapped binary
config files -- dconf is the best solutoin for this. We already have a QtDConf
implementation, so we can access the same data. The next step is to have a
shared configuration key-set, what the gnomies call the schema (what keys store
what properties and what their types are). To be honest, I've never looked
into the schema in detail.
One remaining issue is to have an "alternate representation" for certain types
in the data, most importantly strings. As I provoked in the Enlightenment talk
in the Summit, when Gustavo was calling for shared, binary formats, "strings
are UTF-16, right?"
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel