glib in kdesupport: yes or no?

Havoc Pennington hp at
Mon Mar 10 05:50:02 GMT 2003

On Sun, Mar 09, 2003 at 08:58:14PM -0500, George Staikos wrote: 
>   1) Communication, here in The Internet Age, gets an F.  Most KDE developers 
> have never even heard about DBUS, at least not until this past week.  How do 
> you expect people to accept such things if they are left out of it until the 
> last minute?  These hundreds of developers are being asked to change the 
> foundation of the core of their system to code not written by them, not 
> designed by them.

Keep in mind a couple of things, 1) D-BUS is maybe 30% done if that
and still open to large changes 2) there were more KDE developers
initially involved than GNOME developers, quite a few people (a
dozen-ish I think?).  The whole thing was more or less Matthias
Ettrich's idea as I understand it, though he hasn't had a lot of time
to work on it.

I've been relying on the KDE developers involved to tell KDE about
D-BUS, rather than doing it myself; I have my hands full selling it to
GNOME as some may have noticed if you lurk on our flamewars. ;-) But
I'd be happy to do a 'briefing' for this list.

I'd encourage everyone to get involved and to look at the
design/implementation. The list archives contain all discussion that's
occurred and have always been public. Also please feel welcome on
#dbus on freenode. We'd still be eager to make *any* changes that will
be desired for KDE adoption, though I admit I'd rather hear about them
in the next few months than next year, because I do want to start
using D-BUS in systemwide mode soon (that is my excuse for hacking on

An important question for KDE is, *if* you were going to use it in
addition to or instead of or as a backend for DCOP, how would that
migration work, and how would the code be set up.  e.g. would you a)
swap out the DCOP backend, replacing libICE; b) introduce a new API
enough like DCOP to be easy to port to, but different from DCOP; c)
keep both DCOP and D-BUS as separate things; or d) some combination of
those or something else. We can design D-BUS to make each of these
paths easier or harder.

My hope is that D-BUS will turn out nice enough technically that
people will really want to use it.

>    1b) This "system" is a system developed by hundreds of individuals, 99% in 
> their spare time to suit their own purposes.  There is no governing body, no 
> pay-cheque.  No-one can impose changes or regulations on these people.  Even 
> if you try, these people will surely revolt and relocate [fork] the project.  
> This is no small proposal.

But the nice part is that I'm not proposing one huge thing. All I'm
doing is presenting a case for a particular goal (interoperability),
and pointing out that this can be achieved via a lot of small,
independently valuable efforts. If we solve the menu system but not
MIME types, menu system work is still valuable. If we do D-BUS but
can't figure out DND types, D-BUS is still valuable.

So any individual can make a difference here. I'm not trying to govern
anyone into doing so, just making an argument for what I think is
right, and if my arguments are good maybe some people will be
convinced. I can't ask for more than that. Ultimately open source
software is driven by lots of independent hackers doing what they
think is right.

>    2) Implementation issues.  At the present time, from what I have seen 
> personally and what has been conveyed to me by others, there are problems 
> with the existing implementations.  For instance, the conversion of so many 
> libraries to pkg-config from bin/foo-config can force people to update large 
> numbers of their packages - in some cases I suspect most of the base system - 
> just to install new KDE/Gnome releases that will depend on it.  This of 
> course assumes that we don't duplicate all the pkg-config checks for 
> non-pkg-config systems, which of course defeats the whole purpose and begs 
> the question "why use it?"  This loss of compatibility reminds me of g*c 
> 2.96.

I think the answer there is just to start using pkg-config to detect a
dependency at the same time that you're adding the dependency (or
bumping the version of the dependency you require) for some other
reason anyway. For example if you suddenly require libxml version
X.Y.Z and it happens to include a .pc file, suddenly it's no extra
burden to require the version with the .pc file.

Similarly pkg-config was introduced with GTK 2, when apps had to
require a newer GTK anyhow.

>    3) Control.  When the desktop begins to rely on external libraries, the 
> developers start to lose control over the system.  We have severe problems 
> with this already.  Example: OpenSSL - breaks binary compatibility every 
> second release, and source compatibility regularly as well.  We are at the 
> whim of the people controlling the common elements.  Conversely, we don't 
> want everyone who uses the libraries with their fingers all over it.  Quite 
> frankly I've seen more bad code than I have good code.  (I am guilty of some 
> of that bad code too, of course.)  Exactly how is this supposed to be 
> administrated, especially considering that KDE - arguably the largest user of 
> this technology if adopted - has no real budget or steady developers.  Even 
> if 

GNOME of course has the same issue. FWIW, I think GNOME and KDE both
have much higher standards and stricter policies than most projects.
We simply take the union of those policies, pick the strictest rules
where there's overlap, and use that policy.

There's certainly a level of trust required here, but it doesn't seem
impossible to achieve.

>    4) Containment.  One of the most annoying things about installing software 
> is having to search all over for dependent packages.  KDE has generally kept 
> these at a minimum, and in fact where we have them, they are often optional.  
> I can't say the same for other projects.  I'm not sure that I want to give 
> this up, and I am quite certain that other KDE developers would agree with 
> me.  Perhaps one solution (but please, this is just a proposal and must be 
> discussed thoroughly with all parties involved) is to package up all of these 
> components as freedesktop.tar.gz.  This could include vfolder, pkg-config, 
> etc.  This suits our purposes, but would probably irritate those who only 
> want parts of it.  Not my concern.  I will not be pleased if I have to 
> download 10 -other- source packages to install KDE on my minimal Linux 
> install.  I don't have to do that right now.

GNOME had a large discussion about this before moving to our current
many-small-packages setup. Basically it turned out to be a non-issue
because we have tools (jhbuild, garnome) that automate everything. So
it's easier now with all the small packages than it was before with 10
or so compiled manually.

However, I don't want to rely on convincing anyone of that, so a
freedesktop.tar.gz is totally fine with me. In fact I made a
gtk-and-all-dependencies tarball once, and did some pkg-config work to
support it (so you can build the whole tarball without installing any
of it).

>    5) Wrappers.  In the end, someone will be using wrappers.  I object to 
> having to obsolete existing and working C++ code to use C code simply because 
> that's the lowest common denominator.  KDE is fundamentally a C++ desktop and 
> as such we want to use the power of C++.  Compiling C code with a C++ 
> compiler just gives us the inefficiencies of the C++ compiler of the day, 
> with the loss of power that was available.  Are the other desktops prepared 
> to accept C++ as a core requirement, and use C wrappers to the C++ code?  Or 
> is KDE to be the one to bear the burden of wrapping C code with C++ to fit 
> the development model?  Will we even have to use C# backend code at some 
> point?

IMO the shared implementation that's needed is small enough that this
isn't a huge issue. It's only a big problem for a couple things
(notably vfs). But, fwiw, GNOME would probably be willing to depend on
C++ (already does really), and no, I don't think we could add C#.

>    Standardization and sharing technology are noble goals indeed.  I
> do infact support this.  I do not support the means to this end
> right now.  I need answers, procedure and compromise, and I think
> the rest of the desktop developers need this as well; KDE, Gnome,
> XPDE, and more.

It's a matter of small steps. We don't have to decide on huge
intractable goals - doing each individual thing, as we have interested
developers or opportunities, will move us in the right direction.
Discussing the big picture is still valuable of course.

D-BUS is pretty much opportunistic for example; we had two developers
(myself and Anders) that found an excuse to spend paid work time on
it, so we are taking advantage of that and trying to get it done while
we can. If we can't get broad acceptance, fine, we both needed to
write it for work reasons anyway - but if it's more broadly useful,
that will be awesome. May as well take advantage of the work.

>    I sincerely hope that we can discuss these issues more at OLS and
> perhaps even come to some agreements.

Ditto, I look forward to it.


More information about the kde-core-devel mailing list