OSNews

The whole thread started when a KDE developer asked the rest of the developers in the list what they would think adding Glib as an (optional or not) library by the kdesupport's dependencies.

"I think that the adoption of glib for certain tasks within KDE will make it easier to achieve such consistency. -- Waldo Bastian

Naturally, others didn't have the same opinion on the matter though...

"We can't very well gain consistency by disobeying our own standards, so GNOME adoption of KDE standards is the only way to get more consistency. -- Neil Stevens

Waldo replied back:

"As the discussion became more heated, the C/C++ issue came about: Your reasoning is solely based on gross generalisation. In most cases C++/Qt is superior to C/glib, however that doesn't rule out that in _some_ cases C/glib is a better choice. In those cases KDE should use it.
[...]
Especially in areas where the KDE standards are more de facto standards rather than documented standards, this can be very helpful to improve consistency. I am not so much thinking in terms of visual appearance here, but more in terms of behaviour, e.g. the opening of a browser to open a URL, the sound-server to use to play a sound.

glib can be helpful there by providing commonly needed functionality without repeatedly duplicating that functionality (which you would need to do if you didn't use glib or Qt) and without introducing rather large dependencies (C++/Qt is a much larger dependency than C/glib). As such I think that glib can offer the right balance in those situations. -- Waldo Bastian

The thread continued about component interchange strategies:

"So as some components of these might be inferior compared to other components, I think its unlikely that at any point in time, a user will get the optimal set of all applications and services from only KDE or only GNOME ; thus, it would be better if code sharing could be improved And yes, adopting glib for KDE is only the first step. [optional] -- Stefan Westerfeld

Which of course is not an easy thing to do:

"It is relatively easy to use common icons or a common system for installing .desktop files. But unifying things like KPart/Bonobo, DCOP/CORBA and the underlying APIs is almost impossible without a re-design of a lot of things. And unifying common dialogs, like the file dialog, would require 100% code duplication and huge coordination problems (because they must be synced all the time - if you change the Qt dialog you must change the Gtk/Gnome dialog at the same time).

If your goal is to unify Gnome and KDE, you would better spent your time on improving Gtk++/Gnome++ and port your applications to it. But maintaining two complex system and keeping them inter-operable at every level is crazy. -- Tim Jansen

Then, it was Havoc Pennington's turn to explain why this interoperability between DEs is very important for the platform and that by interoperating KDE and Gnome, will NOT mean that KDE and Gnome will be the one and the same (which is something that some people think, sadly enough):

"The applications should be orthogonal to the user environment (choice is good, platform fragmentation is bad).

To me whether GNOME and KDE should "merge" hinges on the question of UI unification. Say you merge the human interface guidelines and general approach/goals. Then at that point you may as well start merging implementation (say porting GTK+ to Qt or vice-versa).

However, if you don't, there is still value in ensuring that the apps interoperate - same help system, font system, MIME system, etc. i.e. even if we offer *choice* of user interface, we should avoid *fragmentation* of platform." -- Havoc Pennington

One of the most active KDE developers, George Staikos joined the discussion soon thereafter:

"I fully agree that choice and interoperability are far preferable to fragmentation. Believe it or not, I do agree that pkg-config is in general a good thing. What I don't agree with, however, are the approaches and implementations we see presently.
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.
[...]
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?

Standardization and sharing technology are noble goals indeed. I do in fact 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.

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

Havoc continued by explaining that what needs to be done at this first stage leave the vast majority of existing GNOME/KDE code unchanged. No reason to think about interchanging C++ APIs to C or the other way around. Basic (but important parts) interoperability can be a reality between the two projects without major architectural changes.

"Note that my list is mostly the hardest stuff; the easy things are already in-progress or done and just need maintenance over time." -- Havoc Pennington

He later explained the difference between choice and fragmentation.

"Keep in mind though - the problem with duplication is choice vs. fragmentation, not the mere existence of duplication. As I said before, people *like* choosing from multiple email clients. What they don't like is say not being able to choose the best email client, because of their choice of web browser. Or losing possible users due to choice of devel platform. Or having to set up MIME handlers 6 times.

I think the open source community is inherently going to have 30 efforts in every category, just because there are lots of programmers in the world and they all have their thing they want to try. And in fact users have different needs. That's not necessarily a problem in itself. It gives users choice, and it gives us "failover" (if one project fails we have others to pick up the slack). The problem is when the stuff is not orthogonal/interoperable. If the Linux desktop slows down due to duplication, it will be because of fragmentation (because we had to provide feature completeness in one fragment or the other rather than in some combination of the two halves), not due to choice (if extra apps exist as an option, that doesn't matter).
[...]
It is simply not that hard to get good interoperability; the list of to do items is very finite and very limited in size compared to the full size of GNOME/KDE. In fact we've already solved more problems than remain unsolved. I'm optimistic about our chances for that reason.

There's no progress or plan to be communicated. All I'm listing here is my personal opinion on what's a good idea or how it could be done, that's it." -- Havoc Pennington

Knee Jerk reactions where part of the show too but thankfully they were kept to minimal.

Replies regarding the Red Hat choices followed:

"Ultimately open source software is driven by lots of independent hackers doing what they think is right.
[...]
I don't think this is a productive conversation. I can say "well we care about features XYZ and business concern ABC" and some of those things will be very debatable; there are plenty of judgment calls involved. So those people who are inclined to think we're evil will not believe any of it anyway, and in the meantime we'll have a huge list thread on unresolvable religious issues." -- Havoc Pennington

Scott Wheeler continued the discussion (which now has turned into whether DBUS is a good choice instead of using DCOP):

"I don't think it's fair to expect the KDE community to link to the core libraries of the Gnome project while saying that the Gnome project is not willing to link to the core libraries of the KDE project. I know, I know, "tainted by the GPL" or whatever, but that just doesn't seem like the way that things are supposed to work." -- Scott Wheeler

And two more must reads, one from Havoc and one from George Staikos.

1. "The Commentary"
2. "Thread Summary"