Slashdot Mirror
Common Interfaces for Gnome and KDE Released
An anonymous reader writes "Today OSDL and freedesktop.org announced the release of Portland 1.0, a set of common interfaces for GNOME and KDE. From the article: 'Specifically, these tools make installing and uninstalling menus, icons, and icon-resources easier for developers. They also can obtain the system's settings on how to handle different file types, and program access to email, the root account, preferred applications, and the screensaver. There's nothing new in this kind of functionality. What is new is that developers can use these regardless of which desktop environment -- KDE or GNOME -- they're targeting.'"
Everything is *not* integrated together on Windows. Native Windows apps target different APIs than .NET WinForms apps, which are different again from the upcoming XAML stuff in .NET 3.0 -- and that's just the "Windowing" applications. Getting the disparate technologies to play nicely with each other is a bitch and will likely not get better anytime soon.
And if you're about to copy and paste the MS boilerplate marketing hype about the effectiveness of COM-.NET interop, slap yourself vigorously and back away from the keyboard.
Too simple? I remember my mother's blank stare when she saw Ubuntu shut down for the first time: "why is it sending the KILL signal?"
The Portland API will have an option to turn on more options.
cpeterso
I guess you meant are you right or are you wrong?
We've always been at war with Eurasia.
As I'm reading the comments in this article I detect an optimistic view in many comments that suppose that this is, somehow, going to integrate Gnome and KDE so they have the same programs, appearance or even, from the programmer point of view, that you will be writing applications for either KDE and Gnome without having to choose a specific environment. I think this is far away from reality. freedesktop.org has been very active and successful in providing specifications (and now libraries and command-line tools, it seems) about the location and format of different desktop resources. I think the goal here is that, for example, if a given desktop environment has an applications menu, it can go to a known place and display, add or remove items there, and the changes will be reflected in any other desktop environment you use, so all environments "share" the same menu.
As the article mentions, the desktop resources it tries to unify are the applications menu, the icons and icon themes, the mime types (that is, which application to be used for opening this type of file) and several other aspects or "concepts", if you want to use that word, shared among desktop environments. This is far away from a merge in desktops or desktop APIs. First off, Gnome is written in C and KDE is written in object-oriented C++. For that to happen, you either would have to start writing Gnome apps in C++ or convert KDE to plain C (ha! good luck on that!). I suppose now the Gnome people will proceeed to update/rewrite the relevant parts in the Gnome libraries and apps so that when they need to add a new icon set, they will use this new interface and the icon set will be installed "across desktop environments". The KDE people will probably proceed to either update the relevant apps to use the new API or maybe integrate the API using an object-oriented inside the KDE libraries. Or, if something similar is already abstracted in one or more classes (I suppose it probably is), refactor (reimplement, replace the internal workings) those classes and recompile. But, in any case, KDE will be KDE and Gnome will be Gnome, and each one will continue to work its own way and have its own libraries. The difference will be that they will now share another small library to allow desktop resources to be shared. And this can be extended for any other desktop environment using the new API, like it could be XFCE4 or Enlightenment or whatever. The new API is probably in C, so it will have bindings or wrappers for many other languages.
If common interfaces are going to be adopted by KDE and GNOME, at the same time some GNOME- or KDE-specific libs should be abandoned.
That's right. It's pointless to have two different sets of libraries. Since the KDE libraries are clearly far superior to the GNOME ones, the KDE ones should be adopted and GNOME-libs abandoned.
GNOME advocate: Hey! The GNOME ones are better! Let's abandon the KDE libs instead!
[argument ensues]
That, in a nutshell, is why we have both. As long as there's people willing to work on them, and people who want to keep using them, both sets are going to exist. There's no know-nothing manager with the power to force people to abandon anything here in the OSS world.
Bluecurve is basically a disguise: you set up KDE and GNOME so that they look the same. It's purely aesthetic.
Portland is about communication -- getting GNOME and KDE apps to talk to the opposing desktop more reliably.
Example: both GNOME and KDE provide screensavers. Suppose you have a media application that wants to disable the screensaver while it's playing. Now suppose the app is a KDE app, but you're running it under GNOME (or vice versa). Portland makes it simple for the KDE app to contact the GNOME screensaver.
It's an abstraction layer. You tell your apps to target services through Portland, and Portland will contact whichever service is actually running. Theoretically more desktop environments could be set up to provide the potland APIs, allowing a GNOME app to contact the XFCE screensaver, and so on.
Try comparing it to having sex with either Roseanne Barr or Kate Moss. The basics are the same, but I'm sure look and feel alone will create a preference of one over the other.