kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)

[Thiago Macieira]

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.

kdontchangethehostname

> 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.

Yes.

> 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...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110820/2d0c7574/attachment.sig>