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.'"
...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/
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."
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."
Doesn't "free as in speech" pretty much rule out the possibility of imposing a standard GUI toolkit? It's not like quality is even the determining factor either or GNUStep would be far more popular than it currently is.
Linux == freedom == lack of unity. It's simply a fact of life.
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?
So these two choices somehow aren't imposing?
1 = imposing, standardized, violation of principles, united
2 = Free as in speech, touchy-feely, all is well, infinite possibility/not united under anything, Thunderdome-y goodness of creativity....
I've never really seen the point behind having two different interfaces in the first place. They're both the same for the bulk of people: Menu with applications, taskbar/panel/whateveritiscalled with various accessories/widgets. The only difference seems to be what the icons and decorations look like. Whoopdie-flip! Linux will never conquer the desktop until a desktop conquers linux.
When our name is on the back of your car, we're behind you all the way!
No, because that's just a window manager, not a full desktop environment. Perhaps you meant to say "You mean, like, CDE?"
Perhaps, but a third popular desktop platform has two of them - Carbon and Cocoa. (I assume Windows is one of the two; what's the other one?)
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 Seattle native likes the "Portland" name, too. :-)
I'm just glad they didn't name the project "Chicago"...I'd hate for any Linux software to be confused with that fiasco.
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.
No, no, no... Blackbox!
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.
The real Portland is in Maine. :)
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
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
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!!!!
With the addition of .net, Windows has at least two. More if you count MFC and 16-bit apps.
Comment of the year
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!
The real Portland is in Maine. :)
The real Maine is on the bottom of Havanna harbor...
I miss old-school enlightenment.
Not for long... Apple been telling developers to switch over to Cocoa for years. What happen? Apple switched over to Intel CPU family, programs in Carbon (i.e., Adobe Photoshop and Microsoft Office) got stuck on the sidelines and programs in Cocoa became Universal binaries with a simple compile.
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.
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.
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.
Right. So which one should we pick? I choose KDE, but I'm sure there's plenty of people here who would choose GNOME. How do we get everyone to agree on this? This isn't an organization with a clear heirarchy of leadership.
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
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.
Perhaps, perhaps not.
Was that purely because the programs used Carbon, or was it because they were developed using CodeWarrior?
...assuming the program doesn't explicitly or implicitly assume a big-endian machine.
+8 Geographical Superiority
(I tend to refer to that other city with the left-handed ocean as "Portland Jr.")
Save Maine's economy: write stuff down. All comments are exclusively my own, not my employer.
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.
Are we talking about widget sets or APIs? I'm a little confused. Oh well.
I mean, OS X has just one widget set, but both the Carbon and Cocoa APIs make use of it. So you're also arguing that OS X only has one "toolkit" by that reasoning.
(Once again, Slashdot's bug where the Submit button will do a Preview in the Safari browser rears its ugly head. What the hell do you have to do to get bugs fixed around here?)
Comment of the year
'Cause if you put Roseanne over Kate, you'd never see kate.
Nope, no sig
Wow, modded down to zero... that sucks, dude.
For the record, I completely agree with you. (Which will probably get me modded down too.)
A single tookit (or at least a single well-defined API) would do wonders for app development.
One thing that I do know, is that although Gnome has always been incredibly faster than KDE, so long as that absofuckinglutely AWFUL Gnome 2.0 file Open dialog is still there, i won't even use any GTK APPS, because they are all fucked.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
Wow, modded down to zero... that sucks, dude.
Eh. If you spend your life wondering what stupid people who don't know what they're talking think about you, you'll never wind up doing up anything useful or interesting.