RFC: DBUS & KDE 4

[Lubos Lunak]

On Thursday 30 of September 2004 01:23, Maks Orlovich wrote:
> On Wednesday 29 September 2004 06:53 pm, Michael Pyne wrote:
> > On Wednesday 29 September 2004 03:59 pm, Maks Orlovich wrote:
> > > On Wednesday 29 September 2004 11:51 am, Harald Fernengel wrote:
> > > > nope, there's no glib dependency. The API is a bit glib-ish, but we
> > > > don't care since we do not expose it in our wrapper.
> > >
> > > We thought something like that about aRts, too.
> >
> > We think of Qt as a good wrapper around Xlib, so there's no reason that
> > there can't be a good Qt wrapper around D-BUS (or almost any given C API
> > for that matter).
>
> Xlib is -old-. It's mature. It's stable. And it still has bugs. Thankfully,
> people like Lubos are willing to fix them when they affect us. Oh, and BTW,
> Qt is hardly a wrapper around X.

 I guess you mean wrapper around Xlib, since Qt certainly is a "wrapper" 
around X. Xlib is just an implementation of the X protocol, saying Qt is a 
wrapper around Xlib would be like saying KHTML is a wrapper around HTTP.

 And just for the record, I think I'd rather fix bugs in Xlib than implement 
KXlib from scratch.

>
> Anyway, my point was not about quality of wrapping. It's about the fact
> that you can't fully count on someone else to maintain something.

 So you suggest we also create libkpng, libkX11, libkxml, libkart_lgpl etc.? 
Yes, relying on others sometimes sucks - e.g. right now with fontconfig, I've 
identified the performance problem, I've reported it, and I don't know what 
is going to happen with it. Fontconfig seems to be Keith Packard-only show 
(with few small things from other people), and this probably doesn't score 
that high in his TODO :(.

 But even with this, I'd rather learn how fontconfig works and do the changes, 
than starting kfontconfig just because I cannot get Keith Packard to fix the 
problem next week. A lot of work and testing has already gone into 
fontconfig, it works I guess, I don't care about fontconfig at all besides 
this one problem, and I'd feel like a complete idiot for writing once again 
something that already is there and works (indeed, every young developer 
knows they can do the best - I guess I'm not young anymore :-/ ).

 Just stamping a big K on something to please people suffering from NIH 
doesn't fix anything. The most important thing needed are people willing to 
work on things, and doing so. If we don't have them, and there are such 
people elsewhere, we should use their work. Just ask any KDE developer to do 
something for you, and you'll probably hear something about okay, but not 
having much time.

 Have a look e.g. at the screensaver stuff - it was basically xscreensaver 
copy&pasted into KDE, with some configuration GUI added. And I felt like 
beating whoever had done that, instead of simply adding KDE GUI to 
xscreensaver and using xscreensaver directly. We could have the xscreensaver 
people adding more weird screensavers, fixing the bugs, and what not. No, 
instead, if my memory serves me well, the stuff went unmaintained for a 
while, and then it was me, grumbling and later cursing, who started fixing 
the stuff, and eventually gave up and did a large copy&paste from newer 
xscreensaver. Completely unnecessary work, the xscreensave people were 
willing to do this for us, and I could have been doing something useful 
instead.

 ... </rant>

> Sooner or 
> later they will move on. And hence, the more people can maintain something,
> the better. My contention would be that aRts failed in large part because
> there are are very few people who can touch at least part of it, and only 1
> person who understands all of it. Hence, broken stuff stayed broken,
> because even when people were willing to try to brave the widely different
> codebase, few could actually understand enough of it to try something.
> Now, 
> you could probably make the case that D-BUS will be well-maintained for a
> very long amount of time, and that no-one here would have to worry about
> it, and that's fair enough, but that doesn't mean that the style of
> implementation has no significance.

 I don't think the aRts argument counts here. Yes, the DBUS developer are 
insane enough to develop it in C, and yes, it's ... erm, verbose, but it's 
still readable. And since DBUS seems to have enough buzz^H^H^Hmindshare to 
gain wide acceptance[*], it should have enough developers. It already has 
more that libICE has ever had. Assuming DBUS works, we shouldn't need much 
more. And if it doesn't, there are people who are willing to fix it for us. 
But that indeed assumes we actually tell them.


[*] Just consider Aaron and his systray-over-DBUS. He knows DCOP, and he's 
been told by me a couple of times that DBUS is not the right thing for 
systray (let's ignore the question whether I'm right or not). And yet he 
wants to use DBUS. Now, what will people needing some kind of IPC do, who 
don't know about DCOP and are being told DBUS is the best thing since sliced 
bread?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/