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.'"
How is a common API going to reserve the differences in user interface? GNOME keeps things simple, a little too so for many users, why KDE is known for making more options 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.
There is development to get it to work under windows. It already runs on OS X though compiling sometimes breaks because of various differences in low level libraries. Hopefully when I do the next release this Friday it will compile fine. I think the last thing needed to be done on OS X is to propigate the session bus' address. We do this with env variables and soon X selections on Linux and *BSD but you don't have as much control over the session in MacOSX.
--
J5
Well, urpmi, apt-rpm, Yast, and several others all function basically the same as apt-get and one assumes that talking about apt-get in a generic way without mentioning Debian, they mean all similiar tools. I am not aware of any major Distro that does not have some sort of auto install dependancy tool. Gentoo is sort of an exception as it is an auto-make tool and would take a while to install, hence the joke.
Just a Tuna in the Sea of Life
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.
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.
Interestingly enough, on disk the JDK does take up about 100 MB (after decompressing). This is going by the contents of /usr/lib/jvm on a system with the Java 1.5 JDK.
Not that it particularly matters but, Ubuntu now defaults to quiet/splash boot and shutdown displays (no kernel output; I'm using Edgy). I know because it annoyed me (a less-than-ordinary user) and I turned it off.
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.