glib in kdesupport: yes or no?
staikos at kde.org
Mon Mar 10 18:22:10 GMT 2003
On Monday 10 March 2003 00:50, Havoc Pennington wrote:
> 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.
Are you open to a complete redesign of D-BUS if KDE users decide that it
is not usable in its current form? The design issue is often more important
than the implementaion for something like this. Now that KDE developers have
access to D-BUS lists and know that it even exists, perhaps we will find time
to contribute in a more open fashion.
You have to be very careful about only taking a few developers in a
non-open fashion for such critical decisions at this point in the life of KDE
for several reasons. First and foremost, there are too many developers who
contribute very large portions of their time to KDE. It has grown by leaps
and bounds since 2.0 days even. If you want to change a critical component
of KDE one day, you need to get feedback from the project as a whole.
Second, you cannot rely on a few developers always doing their duty in a
timely fashion. We don't get paid to do this, and we can disappear for weeks
on end. The points of failure have to be taken into account.
> 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.
If only I had enough time for the KDE lists alone...
> 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
As would I. Please, KDE developers, join the DBUS discussion and
development cycle. I just don't have time to contribute much personally,
other than the occasional comment. I know some of you will have much more
feedback about this though.
> 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.
I spoke with a few KDE developers about this too. I suspect we will have
to make a bridge between DCOP and D-BUS, keeping DCOP around for backward
compatibility. If D-BUS lives up to expectations, hopefully it would become
the new internal API and mechanism for KDE with DCOP apps being bridged over.
Having two separate, unintegrated RPC mechanisms is a bit silly. This is
IMHO of course. We have to make sure that D-BUS is at least as easy to use
for the developer as DCOP is. That means the API must easily support calls
and signals the way we have them now. Some of this will be our own
responsibility of course.
> My hope is that D-BUS will turn out nice enough technically that
> people will really want to use it.
As do I. I don't however believe in change for the sake of change. It
really needs to provide tangible benefit to KDE. One thing we really could
use is better secure, remote support. DCOP is rather lacking in that area
right now. Unfortunately DCOP is really not network enabled the way the rest
of KDE is.
> > 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.
They all add up to a big change in direction, and I think in many cases the
real benefits of one change are not realised until other changes are also
> 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.
That is probably the best approach. More dependencies still do hurt
though. From what we've seen over the past week, we may not have a choice
about pkg-config anyways. (regarding glib, on the other hand, I believe we
still have an easy choice there)
> > 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.
I think it might be more difficult than you think. I will be surprised if
there are many libraries at all that both projects agree upon, for instance.
Perhaps libxml (already), pkg-config (for KDE 3.2). We almost always make
external libraries optional anyways. This is what I am requesting for glib
also. I don't see why glib should be required because a KDE required
component has decided to require it, while other KDE components have gone to
great lengths to make their components optional. What would happen with the
"freedesktop" packages? Would they become required components to build
KDE/Gnome/other desktop? Once there is a required component like this, I
think KDE needs serious control of the direction it heads in. Of course, so
do the other desktops. I think it is for this reason that KDE will never
share a "VFS" with any other desktop unless the other desktop adopts KIO.
> > 4) Containment. One of the most annoying things about installing
> > software is having to search all over for dependent packages.
> 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).
I definitely prefer this. Especially from a developer point of view, but
also as a user.
> > 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),
I think this remains to be seen. We need to see some components mature.
I don't know of too many projects that end up with less code and fewer
interfaces than originally predicted.
> 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.
I think discussing the big picture is critical. Complex projects need to
have a focus and a goal, even if it is far ahead in the future and done in
baby steps. Taking many baby steps blindly (with no direction) is perhaps a
scary situation in that there is no idea of where we will end up. We need to
know why we are taking these steps in the big picture of things. If there is
no big picture, there are probably better places we can spend our effort.
That would certainly not help your goals of choice vs fragmentation.
> 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.
Of course! Great example! The learning experience is worth the work
More information about the kde-core-devel