RFC: DBUS & KDE 4
l.lunak at suse.cz
Thu Sep 30 16:31:36 BST 2004
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
> 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.
> 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
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/
More information about the kde-core-devel