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.'"
I hope that this doesn't result in a net addition of one more package that users have to install. 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. Duplication of function sucks for end users having to install all kinds of stuff, and it sucks for developers too since there's more code to maintain.
Sounds good to me. As long as it ends the Gnome/KDE flamewars and eliminates some of the rampant duplication of efforts between both "platforms"...
Like, maybe we can get one mail client that's really good, instead of two half-baked ones, etc.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
You're telling me they could have called it "Beaver" instead?
Think of how many more +5 Funny's we would have had.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Bluecurve made a standard GUI appearance for users. This project gives a single API that developers can use when writing applications, so they can run more comfortably on both GNOME or KDE.
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.
Looks like you got caught up in the overloaded use of the word "interface". You're thinking in terms of the GUI, but this is about application interfaces. KDE and GNOME will still look as different as always, but now applications can use a single interface to install menu items for either KDE or GNOME. This is good. It's one step on the long road to wooing commercial ISVs onto Linux.
The only open question is whether or not this will work in the long run. For example, at one point the LSB was supposed to standardize filesystem locations across distros so that installers wouldn't have to know if your distro uses "/etc/http.conf" or "/etc/apache/httpd.conf" (LSB appears to have dropped that pipe dream). If distros and developers don't pick up and use these new interfaces, it doesn't much matter that they exist.
I know I'm gonna get modded down for saying this ...
Stupid self-martyring twat. I wish slashdot would let us filter out comments that start with this phrase, or maybe have the lameness filter nip it in the bud.
Wouldn't it be cool if you opened up "My Computer" and had a drive for every letter of the alphabet?
Plus, not to put too fine a point on it, this will be one more thing that developers will have to worry about. Right now, we have something like:
if (kde) { -stuff- }
else if (gnome) { -other stuff- }
else { -handle neither being installed- }
Now, well have something more like:
if (portland) { -stuff- }
else if (kde) { -other stuff- }
else if (gnome) { -yet more stuff- }
else { -handle neither being installed- }
Is it that big a deal? I don't know, I don't develop Gnome/KDE apps. (I wish I did!) But I hope that it either sweeps the G/K development world by storm and is adopted very, very quickly, or that it dies immediately. Otherwise, it makes things more complicated, not less.
Probably to make it easier for developers to more cleanly support two different kinds of users with their applications? Developers have little control over which desktop a user decides to use. Personally I hope that desktops don't end up uniting in a way that restricts the choice for a user.
This isn't about uniting the user interfaces, though. It's about making things more convenient for developers by providing a common set of developer interfaces, helping developers to make applications that will work more smoothly with either desktop, and in the longer term, maybe even other desktops that don't exist yet.
I guess you meant are you right or are you wrong?
We've always been at war with Eurasia.
That already exists; just run gconf-editor, or Applications->System Tools->Configuration Editor if you prefer menus. This gives you access to all the settings that actually exist but don't get exposed. You can also set these on a system-wide basis for all new users, either by editing the system-wide files, or using sabayon (which lets you edit the default settings in an Xnest session).
For settings you want that don't exist, either (in order of preference):
As for the rest of your post, it sounds like you have support problems caused by different distributions doing things in different ways; I suggest either standardizing on one distribution company-wide (which you can easily do as long as your employees have no preferences amongst them, generally true for most non-computer companies), installing a separately-packaged desktop environment distribution into
Sir, as a layabout whose sole owned tool is a bottle opener, let me assure you that this saying is untrue. More's the pity.
I quit!
> The strength of Windows in the corporate desktop is that everything is integrated together.
Wow, I want the version of Windows you've got!
Advanced users are users too!
No, not unless CDE adopts it, which is probably pretty unlikely at this point (I'm not sure anybody's actively developing it).
However, the press release nonwithstanding, this is not intended solely to be used by KDE and GNOME; the FAQ lists XFCE as another probable supported desktop environment.
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.
Specifically, these tools make installing and uninstalling menus, icons, and icon-resources easier for developers
.desktop files for menus and application icons.
;-)
Aha.
Developers already have easy
And KDE and GNOME applications already (should) use KDE and GNOME icon resource interfaces anyway, the standardisation here is primarily a level below, in the desktop core. Desktop-agnostic or -ignorant applications tend to have sufficient legacy/NIH/individuality in them to not use these new tools either.
But even if it's all true: this is minor stuff. For example, OpenOffice, The GIMP and Firefox will still look odd on a KDE system. Not using KFileDialog (with global and app-specific bookmarks, full KIO network file support, etc) would be one of many dead giveaways. Throw in a bit of Oracle (Java interface) and Skype (Qt interface) and it becomes clear that menus and icons are not in the least bit the worrisome concerns about desktop standards.
The discussion after the Portland announcement (1.0 planned for June, sure) on here confirms my suspicion that end-user widgets are far more important than menus and icons, but nonetheless kudos to the developers. I just hope their next improvement will actually be significant.
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.
Well,it'll allow toolkits to put them the right way around for the desktop you're on - version 1.6 of the API doc has a ButtonOrder() API to let a toolkit determine the appropriate button order for the desktop on which it's running.
If that's not what you consider the right way around, either switch to a desktop that puts them in the order you want, try to get your preferred desktop to put them in the order you want, or try to get them to offer an option to control the button order. Portland doesn't exist to standardize the look and feel of desktops, it exists to allow applications written for one desktop to work better on other desktops.
You just described Windows.
/opt if you really want to segregate stuff out, but /usr, /bin, /sbin and their ilk work perfectly fine. If you want to find something on Linux, use "which " or "whereis " or "slocate ".
Seriously.
The KDE menu works fine (I can't speak for GNOME as I don't use it); a standardised storage location is all that is needed.
And the "more common area to install the software" is
Goten Xiao
Why should Linux neet to "overtake or compete on a widescale in the United States or Canada"? If you mean compete with Windows, there's not really a comparison. Linux is a kernel -- Windows is a Kernel and OS.
It'd make more sense to claim that KDE (for example) might compete with the Windows UI one day. Specifically what's running underneath it isn't really relevant. In any case, I don't see why KDE and Gnome would need to unify for a non-Windows interface to become competitive.
I was walking across a bridge one day, and I saw a man standing on the edge, about to jump ... are you religious or atheist?"
off. I immediately ran over and said, "Stop! Don't do it!"
"Why shouldn't I?" he said.
I said, "Well, there's so much to live for!"
"Like what?"
"Well
"Religious."
"Me too! Are you Christian or Jewish?"
"Christian."
"Me too! Are you Catholic or Protestant?"
"Protestant."
"Me too! Are you Episcopalian or Baptist?"
"Baptist."
"Wow! Me too! Are you Baptist Church of God or Baptist Church of the Lord?"
"Baptist Church of God."
"Me too! Are you Original Baptist Church of God, or are you Reformed Baptist Church of God?"
"Reformed Baptist Church of God."
"Wow! Me too! Are you Reformed Baptist Church of God, reformation of 1879, or Reformed
Baptist Church of God, reformation of 1915?"
"Reformed Baptist Church of God, reformation of 1915!"
To which I said, "Die, heretic scum!" and pushed him off.^W^W^W^W^W^W^W"That's ok, I am from 1879, but we can be friends anyway!"
DYWYPI?
The other thing is that I cannot do the simplest file operations in the GNOME file selector. Will the common APIs solve this [burning] issue?
QT has versions available for Mac and Windows, and uses native widgets where possible.
Learning HOW to think is more important than learning WHAT to think.
The idea that GNOME apps would appear automatically in KDE menus is a great one, and a good thing. Some commonalities are a good idea too.
On the other hand, Linux's big strength, in my mind anyway, it that there are all sorts of different users. Hand holding types of interfaces for grandmas, and a glorified CLI for minimalist geeks. The rest of us are probably distributed across the spectrum. The point is that there is something just right for everyone.
Let's not be blinded to what makes Linux a great OS by the "beating Windoze by imitating them, but doing it better" mentality.
'Cause if you put Roseanne over Kate, you'd never see kate.
Nope, no sig