A KDE developer tipped me off to a recent thread discussed in the kde-core-devel mailing list regarding interoperability between KDE and Gnome. OSNews featured an interview with the usability experts from Gnome and KDE a few days ago and we expected that the spirit of co-operation would continue to get stronger every day. Luckily this is true regarding most of these developers, but not for all of them are sharing it. Here is a commentary on the issue followed by a summary of the long thread.
It is well known to the readers of this site that I am for interoperability when it comes to the two main X11 desktop environments, KDE and Gnome. In my opinion, this is the only way forward for the Linux desktop’s massive adoption. Most Linux graphical apps are written in either Qt or GTK+. And every new platform needs as many quality apps as it can get (BeOS taught me as much at least…) to stay viable. Therefore, it is important for any Linux-based operating system company to be able to support both. Red Hat was the first distro to make the big step on trying to unify the look of the two toolkits with the use of the BlueCurve theme. Freedesktop.org goes a step closer to a more real integration that would bring an end to the problems we get today between the two environments (major app behavior differences, no full DnD support for all apps, different dialogs, UI HIGs, menu system, notification area etc etc).
All these differences are a huge pain for the average user. Expert users, or users with a ‘religious’ background (against the one or the other DE) will assert loudly that they don’t mind having a different breed of apps running under the same desktop while others will assert that they either run GTK+ apps or only Qt apps and that they don’t bother with the “competitor’s” offerings… Sorry, but the big Linux companies I know ALL want to have full interoperability and same app behavior and looks for both their Gnome and KDE and the same goes for the average user. Why? Because it makes sense! The userbase these companies are trying to capture are Windows users who are used to seeing apps that work and look the same, no matter the toolkit or language they were written on or compiled with.
The Linux platform today is not necessarily the 1996-era 2-hour afternoon hacking project by Joe Developer from his bedroom somewhere on the planet. There are still some elements of this, and Linux is still a great OS for hacker projects, but all in all it has become more corporate. Not acknowledging that fact would be a mistake. The largest pieces of code for the main OSS projects today are written by companies who have adopted OSS as their business, not Joe Developer. Joe is still there, but more and more code is coming from these companies.
These companies do not necessarily have the same needs as the hobby hacker team might have. Joe might not care about Gnome, and Joanne might not care about KDE, but Red Hat, Mandrake and SuSE care for both of them, because the Linux applications their users want to load happen to run on both of them. So interoperability is a must for them. They either do whatever is necessary to build the user experience in a way that will please their users or, both themselves and the Linux platform in general are going nowhere in the desktop. Plain and simple.
Take Apple as the example. They have support for 3 different toolkits, Carbon, Cocoa and Java. And applications written in each will look and behave pretty much the same way when they’re run. And that alone is a reason for someone to switch to MacOSX. Same goes for Windows’ three supported main APIs. All look and feel the same. Even Qt and Tcl/Tk and wxWindows are careful to offer support for the Windows look and feel for their Windows versions, simply because it is important to do so.
And this is what Red Hat, Mandrake (with their new Galaxy theme), Freedesktop.org and even SuSE want to have. There is nothing weird about it. It is business as usual and in fact, it is business that would help the whole Linux platform in the long run, not just the individual distro in question.
I believe that the real problem in co-operation between Gnome and KDE (as I see it in the mailing list discussion) are the people who don’t work for these companies. These people (thankfully not all of them 🙂 don’t view the world with the eyes of someone who wants to make a better (commercial) product. They view the OSS world with their own political agendas, which sometimes go back to 1996 for issues that are completely resolved now. They view the “competitor’s” project with skepticism and distrust and they are the ones who separate this OSS project from the other OSS project. These hackers are doing a lot of work for free, and the community is grateful for it, and I am too. But what I don’t like is allowing these independent hackers get in the way of evolution because of their own political/religious agendas. That would be a major mistake for the further adoption of the Linux platform as a viable desktop alternative. In fact, some think that KDE (or Gnome) is already an almost perfect alternative to Windows or Mac — while this is just not true. And very thankfully, most usability engineers that happen to work on Mandrake/SuSE/Red Hat (the big three), agree with me. There is a lot to be done yet, and this road goes through the unification of the specs and sharing of code between apps that are depending on Qt and GTK+.
Some said that trying to do all this “sharing” work could put a break on the two DE’s effort on adding more features. However, do you rather have Linux never get adopted by the desktop market just because our hackers were enthusiastic to add more features (and more pref panels 😉 instead of doing the tedious work of modifying things under the hood (that the users can’t see with a “naked eye”) but which will enable them to go forward as a whole? Point is, there is work to be done and by postponing this work at this critical point that the Linux platform stands today, would be a mistake. Both camps will need to make sacrifices and might even change libraries or code that a dev really likes a lot but for the good of the interoperability, it is something that has to be done.
Back in the ’80s Unix lost its unity and the leading Unix companies could not agree on specs, standards or on fair competition between each other. That was one of the reasons why Unix became weak in the early ’90s and Windows started to take off. Don’t let the same happen today, as the Unix philosophy has a second chance with they sustained hype around Linux. Unity will make the whole platform strong, fragmentation will destroy both of you. Let history give you a lesson and don’t redo the same mistakes over and over again over religious matters…
And make no mistake: “the common standards that were defined up to now didn’t make KDE nor Gnome lose their individuality”. Choice is good and choice will remain. Nobody is saying to make Gnome and KDE the same project! What is needed are just some common standards that will make the life easier for the user and the application developer. Each project will retain its individuality, but instead of having, for example, a Gnome item working via the notification area in the gnome taskbar just fine and then you run the same app under KDE and you get the notification little app as a real window and not on KDE’s notification area, that is very bothersome for the user. Or when DnD doesn’t work. Or when copy/paste doesn’t work correctly for some apps still (despite the X standard). All of these issues need to go away. It is the only way for users to stop criticizing how “clunky” XFree is, while XFree has nothing to do with this whole issue…
The second biggest problem in the cooperation of the two projects is poor communication. I would advocate that the core developers and usability engineers of BOTH projects should join a kde-gnome mailing list, or simply subscribe to freedesktop.org’s mailing list, and start writing the code required.
However, it is not all “hacker’s fault.” Don’t get the wrong idea please. Companies need to communicate better with the hacker community as to what they have in mind on doing next. And also communicate with both projects! Red Hat should be more active in the KDE list and SuSE/Mandrake should be more active in the Gnome list. They include these projects in their products so it only makes sense to be the driving forces on both camps regarding peaceful co-existence and co-operation. And they should give equal chance and support and respect to both projects. They should be the bright example. (However that doesn’t mean that the KDE ‘About Box’ should be present on each and every Qt app. That’s duplication of information and as KDE is free software, modifications are allowed as long they don’t violate their license. This is to say that companies will modify things sometimes that might be disturbing to the project’s line, but might make absolute sense in the company’s line. I am personally ok with this because I understand the needs and HIGs involved – as long they are legal.)
However, if no middle ground is to be found between Gnome and KDE (I pray that this won’t happen though) we might see forks from the really big distros. And that won’t be good for anyone. If a company is forced to take such actions (simply because their customers are asking for it) that can only be a bad thing for the forked project. And if that company which might do a fork has become in the meantime a 800pound gorilla, then after a few years the original project would be forced to comply with that company’s modifications/standards anyway, as it will be seeing its userbase fleeing and they will be the ones who will suddenly become “non standard” funnily enough. What I described here is a long shot, but it could happen. Just pray that it won’t.
I can only suggest that Gnome and KDE developers keep open minds, think outside of the box and most importantly: think about the long run, not just the “today.” The Linux platform today has different needs that it had 5-6 years ago. People expect a lot from it, expect it to live up the the years of hype. The big three are trying to deliver the goods with the help of many “enlightened” individual hackers, but others are just stuck in their own agendas and “traditional/romantic” way of seeing things. These “backwards” people can become the culprits for holding back wider adoption of the Linux desktop. People overall will have to think more broadly, trust, work together and communicate better.
At the end of the day, there is no Linux distribution company which would like to see its Linux-based products get hurt (except SCO maybe ;), so by helping out the “bigger, more important plan” can only help everyone, not just those few that you might like or dislike.
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
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