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.
