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.' "
Part of the problem that has haunted Open Source is the fact that there are many people willing to develop their own code because the code that they have been using "doesn't quite cut it." Don't get me wrong, that is also part of what makes Open Source so great. It can also be it's downfall. GNOME and KDE being a potential example of this. Although both were designed as an X Environment, they have-for the most part-gone seperate ways in how each interacts with X.
By meeting on common grounds on certain issues, they are giving your everyday user (such as myself) better choices without much hassle.
Now keep in mind, these are my opinions...I am not all knowing, and not a very good speller. Please feel free to correct me if I am wrong.
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
Ah - but here's the problem. (My understanding is that any 'compound document' whether OLE or OpenParts is potentially an executable.) Sometimes you actually might wish to have scripts running automatically. (Think of JavaScript web pages for example.) As Microsoft has proved, flashing a "Do you really want to do this?" dialog box is no protection against stupid users.
You can get around this by sandboxing, but the solution in Lotus Notes and MS Office 2000 is the ability to have all script macros cryptographically signed. An administrator-controlled excution control list defines what runs and what can't run. A client-server approach might also work, but it's looking like both Gnome and KDE are pretty much desktop-oriented, and some sort of controlling server might not jibe with Linux culture.
Anyways, the standard Unix security answer of "it's a user space issue" ain't going to be good enough here. All MS Office viruses running under NT are user space only, and they're still raising plenty of hell.
It's great to see that minds are converging on this issue. This give open projects a chance to develop a much better implementation than Microsoft, as well as develop an alternative to OLE/COM, which is pretty much the only game in town as far as user apps go.
--
Business. Numbers. Money. People. Computer World.
One thing not mentioned in this snippet, but which I've started to notice, is that KDE, and KOffice in particular, is moving more and more towards using the Artistic License.
There is a perception (right or wrong) that the GPL cannot be used with any non-GPL libraries. Since Qt is free and open, but not GPL, there were many unwilling to touch the KDE code base. Strangely enough, by making KDE code Artistic, it will perceived to be more compatible with the GPL than if it remained GPL.
A Government Is a Body of People, Usually Notably Ungoverned
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.