Slashdot Mirror
KDE & GNOME Cooperate
||Plazm|| writes " Here's an interesting article on what's in the future for these two dev platforms. Maybe they can play nice after all... 'This past week, there has been an impressive show of cooperation between the KDE and GNOME projects involving prominent hackers from both camps. The initial subject of discussion was concerning a common network-connection manager that would enable applications to detect whether an internet connection was currently available or not; both projects had already been working on the issue including two independent efforts from KDE developers Bjoern Kahl and Matt Koss. The discussion diverged to the larger issue of making GNOME and KDE play nice together including related CORBA matters.' "
Does someone want to explain to me exactly what advantages this "network connection daemon" will have over a few hundred shared library lines that call "route" (or play with /proc) and "ifup"?
I've got enough sleeping processes taking up RAM on my system as it is.
Sharing of signal/slot implementations would benifit KDE by removing the MOC preprocessor and improve the flexiblity of their signal/slots. GNOME will get the benifit that KDE libraries and applications will be less tied to Qt and thus more easily reused. Since libsigc++, the Gtk-- signal system, is a close translation of the capablities of gtk+ signal system, this should also reduce the burden of programmers trying to understand the two kits. For projects with multiple frontends, this would be a great help.
Unfortunately, this development is not set to be planned until after the summer when the KDE people start a developers cut of Qt. Assuming that people are interested I can give some directions as to how the translation can be made, but I don't have time to work on it heavily myself. (Preliminary specifications have already been sent to Mosfet.) I can mail more info to other interested programmers.
--Karl
will be the establishment of the common CORBA mappings. I'd love to see KDE's KOM/Open Parts component model broaden to the point where I can easily write an app in GTK+ or GTK--, throw a KOM wrapper around it, and then use it seamlessly with KDE KOM parts. Imagine... A Gnumeric spreadsheet embedded in KWord!
--JZ
Now the question naturally arises, "Which solution is best for the community as a whole"? Should we unify the codebase, thinking that a standard interface would promote application development? Or should we just cooperate and come up with a CORBA standard, but not necessarily an identical codebase, in the hope that such a move would encourage folks to write applications to that standard API and yet not alienate others who like their way of doing things(i.e., there is the die-hard gtk+ developer and the die-hard qt developer, one or both of whom could be angered, depending on the implementation). But what about just sticking with the status quo, where a little cooperation exists, but not nearly enough to come up with a standard CORBA API. After all, it seems to have worked pretty well so far, right?
Now let us examine the options we have at hand. KDE, since it uses C++, tends to put off alot of traditional C developers, and GNOME, being C, tends to have very few apps developed for it in C++. Now we could have a big argument about the relative merits of each language, but in my opinion that's pointless, because what we need here is choice--the choice to develop your application in whatever language you are most comfortable using(within reason, of course). Of course, we could do that by consolidating KDE and GNOME and merely maintaining two widget sets, but to me that seems rather pointless, for simplicity and utility is the philosophy of Linux and U*ix in general, so there is really no need for creating a lot of confusion by having a "standard" which isn't really a standard. It would be standard in the sense that all the applications would be written for that single environment, but it would simultaneously be non-standard in that for one desktop environment we actually have two developmental trees, which would probably lead to having two of everything anyway.
On the other hand, we could let things remain as they are, but the disadvantage of doing that is that a developer is forced towrite his application to one environment or the other, or go through a huge amount of effort to make sure that his program is compatible with both standards. This is obviously a great waste of time and energy which could be expended in developing a new application.
Now we come to the solution which I prefer, namely, the development of a standard CORBA API through collaboration between the KDE/GNOME developers. This solution does not, of course, come without its own pitfalls and minefields as well. For instance, both KDE and GNOME could become very bloated in the process of becoming compatible with each other. This is a legitimate concern, but considering the code that we have seen from KDE/GNOME, I believe the developers there are capable of preventing this situation from occuring, and this way the programmer has a real choice as to which language he wishes to use, and doesn't need to compromise by writing to one environment only. It also serves to promote choice for the user as well, since there would ideally be two desktop environments, each with its own respective strengths and weaknesses as interpreted by the user. I don't think we really these environments to convert to the Windows philosophy of a one-size-fits-all Environment for Everyone.
I'm sure that there are things I left out, but this was intended to provoke thoughtful dialogue, so if you have any ideas or input then please, by all means, post them here. I am certain that there are many other things we could do besides the three I came up with. What we need before making any decisions about the direction which GNOME and KDE will follow is a debate as to the merits of each option, so that we may be assured that the one we select to implement(or not, as the case may be) is the right choice.