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

[Oswald Buddenhagen]

On Sat, Aug 20, 2011 at 12:20:55PM +0200, Thiago Macieira wrote:
> On Saturday, 20 de August de 2011 10:02:31 Oswald Buddenhagen wrote:
> > 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.
> 
yeah, at the cost of rather considerable instability.
we should see whether regular service activation isn't the better
option, now that we have it.

> 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.
> 
this doesn't preclude system-specific forks, or even complete
re-implementations. the one thing that is important is the d-bus
interface. systems incapable of delivering that are simply going to be
even less relevant than they already are.

https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html
and the subthreads have all the gory details.

fwiw, macosx has something similar - launchd. it is to be seen whether
kde could make use of it.

> 2) Lennart is also very much opposed to the fork-no-exec solution that kdeinit 
> and booster use to pre-initialise.
>
yes, he made it pretty clear to me that he doesn't like it. but then,
in retrospect, all his arguments seem pretty easy to refute, so if he
is the reasonable person he appears to be, it should be possible to
change his mind if we can make a strong technical case that it would
also clearly benefit gnome.
and in the worst case, the feature is optional and the patch to systemd
wouldn't be extraordinarily big, so we could put it in the hands of
distributors.

> 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.
> 
ksecretservice is a new implementation. dunno how much code was reused.
the arguments against two backends are easy:
- two backends means almost twice the work, including security auditing
- assuming the backends use different storage (it's not part of the
  spec, after all), even after switching desktops you need to stick with
  the now "alien" password manager.

> > 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?
> 
well, yeah. good luck to whoever. :P

> But just as before, I don't see why our code can't be cross-desktop. So no 
> argument in favour of dropping kglobalaccel.
> 
i think it is pretty clear that our *code* is not going to be accepted
as the cross-desktop solution. seeing the reluctance to anything with g*
within our community, why do you think the gnomers would embrace
anything with a q* or even k*, esp. given that it usually weights in at
least twice as much as the typical g* solution?

> 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?"
> 
that's a tough one.
one can't have the binary dbs in utf-16, as then the g* apps would be at
disadvantage.
one could have the string data in both formats at once, but that would
be wasteful.
one could default to utf-8 and let apps switch it to utf-16 entirely.
that would work for application-specific data, but it doesn't cover
global settings.

but then, we have the same problem with d-bus.

so an entirely different approach i've been thinking about for a while:
make QString a hybrid, so it stores raw data and a codec. it would
transcode only on demand, so in many (possibly even most) cases, it
would do 8-bit pass-through. of course, many common "small" operations
would become more expensive. i'm not convinced that there would be an
overall improvement. or even that the exercise makes sense in the first
place.