From kde-core-devel Thu Sep 30 15:31:36 2004 From: Lubos Lunak Date: Thu, 30 Sep 2004 15:31:36 +0000 To: kde-core-devel Subject: Re: RFC: DBUS & KDE 4 Message-Id: <200409301731.36732.l.lunak () suse ! cz> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109655830729499 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. ... > 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@suse.cz , l.lunak@kde.org Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/