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.'"
"regardless of which desktop environment "
You mean, like, mwm?
...it'll be a matter of which widget set you prefer. The api's, however, will be identical for both!
Reality is nothing but a collective hunch.
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.
The strength of Windows in the corporate desktop is that everything is integrated together. This is why phb's love Windows. Corba is a nasty nightmare that makes integration difficult and ole and com+ are much easier to use. Infact iwth vb.net you can create simple gui apps in a matter of minutes.
So is Dbus the answer for Ole and com? And if so when will it be ported to macosx and windows?
We need something to compete agaisnt microsoft on the desktop and also to help integrate different unix apps together. I can imagine sweet rad's and shell scripts for Linux gui apps.
http://saveie6.com/
As an Oregon and Portland native, a really like the choice in name. Since OSDL is in Beaverton (right next to Portland) the name choice makes sense :)
Space for rent, inquire within
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."
I know I'm gonna get modded down for saying this, but the Gnome and KDE people could do the Linux world a favor by standardizing on a single GUI toolkit.
Diversity is great in a lot of places, but not here. The two major desktop platform in the commerical world both have a single UI toolkit. That allows them to have similar look and feel, and functionality across applications, and relieves developers from having to decide what particular subset of users they want to support.
And, yes, I know, I can install both sets of libraries and run apps from either. The point is, why? Pick one thing, make it work well, and move on to more important stuff, like writing good apps. Duplication of effort is pointless here. It's time to standardize.
the point of having different GNOME and KDE interfaces, was so that you could have different interfaces. Now someone wants to unite them, so why even bother having one over the other?
They are both big bloated smoking pieces of crap anyway.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
Okay, I didn't RTFA. What's different about this effort from the old Bluecurve approach which Red Hat Linux tried? I recall there was a general feeling that Bluecurve removed all the GNOMEy-ness from GNOME, and all the KDEy-ness from KDE, making a meatloaf of unified goodness or badness, depending on how much of a fanboy you talk to. Will this just repeat that cycle of fanboy and fanned flames?
[
I hope this will fix the problem of Kubuntu not automatically adding menu items for some GNOME applications that would normally be in the menu.
I hope that existing applications will be rapidly updated to Portland, regardless of what they were originally written for. Finally everything will be a native KDE or Gnome app (whichever you prefer).
Of course this means the desktop projects will have to work harder to maintain their popularity. Up until now they've had captive applications that required their widgets, but if I can switch all my apps instantly from one to the other, and one is clearly better...
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."
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.
This is great for developers that only concern themselves with KDE & Gnome, however, it would be nice to include other Window Managers such as XFCE or OpenStep, etc. Unfortunatly as a developer, it's the fringe window managers that prevent complete adoption of this. Having said that, I think this is a great step in the right direction.
Flexible bare-metal recovery for Linux/UNIX
This kind of stuff wouldn't be necessary if everyone just accepted how much better KDE is! Kidding, just kidding!
*runs away*
How hard would it be to just have an "Advanced Settings" section in Gnome to give the power users the access to functionality they want. And why do we have different locations for menus, icons, etc. It's just nuts. As an admin trying to keep the menus for both Gnome and KDE in sync with the applications installed... it's a full time job. I just want a single location to update menus and icon files in. And would someone please help RedHat and SuSE decide whether /opt/kde and /opt/gnome are going to be used or not. I don't care one way or the other. But please decide. It's a royal pain in the rump trying to admin SuSE and RedHat boxes with the same set of scripts. Royal! There's a reason Linux is having difficulty on the user desktop in larger multi-user environments. KDE and Gnome bear a fair amount of responsibility.
it'll also put the OK and Cancel buttons the right way around.
Am I wrong or am I right?
Summation 2
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 thought in the Linux world it was the Distribution job handle software installation. You have apt-get, emerge and many others that work better than the Windows way. Why are people trying to copy the most bloated functionality of Windows: the ability to install software by 3rd parties? This is a recipe to disaster.
A (standard) database with information about the system is a great idea: what to call when opening an email, or an image, or whatever. But giving each software the responsability to integrate with others is too much.
Everything looks like a nail, doesn't it?
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Do you mean Portland is just another name for Assholetown?
I been trying to move to linux as my OS of choice, but find lots of pit falls if your not a linux nerd trying to setup software and hardware. Not to say that it has improved a lot over the years.
I been playing with Fedora 5 and about 90%+ of that I do under windows I can do under linux.
Somethings I would like to see is a better software installation options and setup the software. This Common interface is a good idea, instead of having the installation program know how to setup both Gnome and KDE. A common x-windows software regestry, in which it would be KDE or Gnomes job to check this regestry for new installations.
Also prompts to select where to locate the software on the menu or create a subfolder on the menu.
Another is having a more common area to install the software, like going through a maze to find program files and folders under linux.
Wise men speak because they have something to say, Fools because they have to say something!!!!
or am I the only one who still uses it? =|
I guess it doesn't really need any of that, or at least I don't.
the only permanence in existence, is the impermanence of existence.
I have. I regularly switch between KDE, Gnome and WindowMaker every few months, depending on what mood I'm in and how I want to do things. They're actually quite different in what they make more convenient to do, and how a user interacts with them.
What I really would hate is if the open source world moved more towards a Windows model, where users have to take what Microsoft decides is "right" for them, because they have no other choice. There's no serious competition in the Windows UI world, because Microsoft has so much control over what can be done, what things look like, and how applications interact. If a vendor comes out with a fancy application with an improved interface, this usually means it's inconsistent with one Microsoft guideline or another, making it generally less nice to use.
The power with having multiple desktop vendors is that although application developers control some aspects of their app's interaction, they don't have to be as concerned about some of the broader parts which are handled by the desktop, because chances are that the user's selected whichever desktop best suits the way they work, anyway.
It's definitely not perfect at the moment, and there aren't that many graphical apps around that run nicely under multiple desktops. I hope that projects such as this one help to figure out the right level of abstraction for applications to have from the desktop.
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!
Isn't that what package managers and dependency managers are for? If you're still manually determining, downloading and configuring packages for your desktop PC, I'd guess it's either because you need a better package manager or because you simply enjoy doing that sort of thing. I'm not trying to suggest that there aren't some popular package managers out there that still have room for improvement, but I'd rather the focus of criticm was on inadequate package managers than on something like Portland which might actually be helpful for developers.
Open source applications typically rely on all sorts of libraries and other packages, and most regular distributions (that I'm aware of) have a mechanism for making sure that required packages get installed. How would something like Portland be any different? All it would mean is that a developer could use a single interface instead of having to distinguish between Gnome, KDE, and whatever else.
I recently switched from a gnome based fedora install to a kde based ubuntu install, and frankly I can see no basic difference with how I interact with the desktop. Everything works exactly the same way. I have a panel at the bottom of the screen, a menu that pops up on the left, What is different between these two user interfaces apart from the icon graphics and where certain apps are on the menu? Help me understand.
When our name is on the back of your car, we're behind you all the way!
Guess whats drawing the widgets in your browser? Yeah, thats right, Gtk or Qt!
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.
There's a GUI toolkit, still in beta, that aims to look the same on all platforms. Claro Graphics is a GUI toolkit designed to be used on all platforms (all platforms being Windows, Mac, and Linux). :)
:)
I only know about it because of the IRC client I use, Besirc.
KDE and Gnome now use the same .desktop files for menus so it only makes sense that
a non-KDE and non-Gnome library is developed for working on them.
Hopefully can be more of this kind of thing.
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.
From TFA: So far, this is simply a nice set of command line tools that allow you to easily do things like install an icon to Gnome or KDE in one simple step.
This is not some huge mega library. The source files for the xdg-utils is only 280k. This is in no way, shape, or form a bad thing for users
This is the single biggest step the Linux community has made toward successfully challenging the commercial desktop OS vendors. Now if only there were a developer library which aided in the design of usable applications...
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?
XFPortland.
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?
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.
For some reason, they've moved to www.windowmaker.info. If you look, the last release was 0.92 in July '05, and they have a month old news item apologizing for the downtime and announcing they are (mostly) back.
Sorry. Somehow I didn't see that you found it yourself.
Now I don't have to deal with KDE's screen loading up in Ubuntu's boot screen after I completely removed the damned thing and went back to GNOME (I went GNOME>KDE>GNOME, so don't get your head up your ass) And now I don't have to potentially worry about KDE-dependent games and utilities. What's still long overdue is a universal, customizable GUI interface, and less of these custom GUI-manager dependent systems (XFCE, KDE, GNOME only. What a waste of resources.)
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
I know I'm gonna get modded down for saying this ...
True and sad, there are too many self imposed kings here who kill the messenger with the bad news. IMO anybody who mods you down is just an OSS-Taliban and does more harm to OSS than any Windows troll. Yet that's the way slashdot is handled and there's no hope except post as AC.
standardizing on a single GUI toolkit
This single GUI toolkit already exists and is named wxWidgets. Unfortunately it supports all kind of platforms except KDE but that's the problem of Trolltech and not wxWidgets.
AC, fearing to be modded down
I just have a monkey which draws on a chalk-board really quickly...
Only on slashdot...
Does a "No it isn't!" post deserve +5, Informative just because it slams Windows? Parent displays total lack of actual understanding by writing "XAML stuff", instead of explaining in detail the proof for his assertions. WinForms *is* "native windows"--hits Win32 just like the rest of them, evidenced by the fact that the first rev of WinForms for Mono used...wait for it...WINE. WPF (the "XAML stuff" mentioned by parent) works the same way. Oh, it has hooks to the new composite UI on Vista, just like WinForms has hooks to GDI+ when run on XP.
While I've heard that argument many times, as a longtime Slackware user who's used to having only what I want in my distro, I've found that that simply isn't how it works in the real world.
The problem is that every application developer chooses their own set of libraries to use, so that to use X image editor I need to install libraries A, B, and C. But then I decide to install Y media player, and find that to get it working I need to install libraries D, E and F, plus add a second audio interface to my kernel. Incidentally libraries D and F are analogous to libraries B and C. And the situation just keeps snowballing as I add more applications to my computer. Eventually I'm left with a huge pile of overlapping functionality, I'm forced to keep multiple versions of various libraries floating around, my kernel has just about everything under the sun compiled in, etc.
I suppose that if I really wanted to I could choose a lean, well-selected set of libraries and features for myself and then proceed to only use applications that work with all of that. But I live in the real world.
'Cause if you put Roseanne over Kate, you'd never see kate.
Nope, no sig