Common Interfaces for Gnome and KDE Released 186
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.'"
Comment removed (Score:4, Insightful)
The danger for developers (Score:4, Insightful)
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.
Re: (Score:2)
My guess is that, if all goes well, the situation you're talking about will just be some growing pain until the next major releases for KDE and GNOME, when they can force everyone to upgrade their code.
But the reality is probably that, since this is the FOSS community we're talking about, neither of the
Re: (Score:2)
Either way, Linux will continue to bloat and bloat and bloat until the end of time.
or not, since Linux is just a kernel, and has nothing[0] to do with any particular desktop environment
[0] for large values of nothing
Re: (Score:3, Insightful)
I assume you do, since you know enough about it to know that yes, technically, Linux is a kernel. Which means I have reason to think you understand what I was say and kno
Re: (Score:2, Offtopic)
Understanding what you say is not difficult, but what you're saying is wrong and misleading which is probably why the parent poster made their snarky comment.
Linux is not a single entity susceptible to bloat. There are big "kitchen sink" distros (Mandriva, Fedora, etc) you might call bloated, but equally there are lean distros which are most definitely not (Vector, Puppy, DSL etc)
Re: (Score:2)
Eventually, some packages will list KDE as a prerequisite, some GNOME, and some Portland, which means I can save precious disk space by using a 10MB Portland shim rather than 150MB of rarely used {GNOME|KDE}.
Moreover, if I wish to create a window manager or desktop environment and have integrated applications, I can simply implement the Portland inter
Package managers, maybe? (Score:2)
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
Re: (Score:2)
The great thing about standards is there are so many to choose from...
Re:The danger for users (Score:5, Insightful)
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.
Re: (Score:2)
I missed the memo where apt-get worked on all systems. And the one that said that there are packages (and package dependencies!) ready for all distributions that do use apt-get. The parent has a valid point, if installation internals for both methods aren't needed, why would it not be better to have only one, preferably the one that is common to both KDE and Gnome? I think it would go miles towards having a standard adopted. (See my next comment...)
Don't get me wrong, packages have come a long way since t
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
Sure every once in a while there is a hiccup... but that's the case with most distros and their packaging managers. I help run my research lab at school... we're all Fedora Core5... and while yum, apt for rpm, and smart update manager do help... I find that RPM's are woefully out of date and lacking in features compared to my Gentoo install at home. In general it takes me a lot longer to inst
Dbus for Windows? (Score:2)
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
Re:Dbus for Windows? (Score:5, Informative)
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.
Re:Dbus for Windows? (Score:4, Funny)
Wow, I want the version of Windows you've got!
Bluecurve (Score:2)
Comment removed (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Insightful)
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
Re: (Score:2)
You're touching on more of the problem. Linux doesn't have a brand name that people can latch on to. They don't care if it's called Linux, Ubuntu, Gnome, KDE, whatever. To them it's Mac vs. Windows, not Mac vs. Windows vs. Linux + Your OS of choice be it Gnome.... blah blah blah. These competing brand names are confusing average consumers that want one easy to say and spell word to describe their "Better" alternative-to-Windows computer.
Re: (Score:2)
Disguise vs. Translation (Score:5, Informative)
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.
Re: (Score:2)
Kubuntu not adding menus for apps (Score:2)
Question (Score:2, Funny)
You know (Score:2)
*runs away*
The KDE/Gnome thing just bugs me. (Score:2)
Re: (Score:3, Insightful)
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 i
Re: (Score:2)
Re: (Score:2)
Then, we have the portability to Win32 or Mac OSX, which is handled differently between Gtk and Qt. Widget drawing under Windows and OSX is handled very differently between the two. Yet another very technical difference.
So unifying them is a bit more difficult than deciding whether or not to display advanced options.
Hopefully (Score:2)
Am I wrong or am I right?
Re:Hopefully (Score:5, Funny)
Re: (Score:3, Informative)
Well,it'll allow toolkits to put them the right way around for the desktop you're on - version 1.6 [freedesktop.org] of the API doc [freedesktop.org] 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
Maybe I got the wrong idea (Score:5, Informative)
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.
menus (Score:2)
a non-KDE and non-Gnome library is developed for working on them.
Hopefully can be more of this kind of thing.
Developers, not users (Score:3, Informative)
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 [slashdot.org] (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.
Re:Developers, not users (Score:4, Insightful)
I think the next sentence is more important:
As an example, I run a GNOME desktop with KMail as my primary email application and a locally-installed Firefox (i.e. not the distro-provided one) as my primary web browser. As things are, I not only had to to tell GNOME that KMail and Firefox are my email and web apps, but I had to track down the KDE control center (which isn't in the menus under Fedora's GNOME config) in order to tell KDE that Firefox was my preferred browser. Otherwise, KMail would try to load everything in Konqueror, because it uses the KDE settings even when running under GNOME.
Targeting an app to Portland instead of to GNOME or KDE would let the app pick up the settings from the desktop the user is actually running (as long as the desktop used the Portland API).
Re: (Score:2)
Ironically, KDE's Control Centre is not in your GNOME menus only because of Freedesktop.org's effort to hide desktop-specific applications (such as the control centre) from menus using the Don't/Only-Show-In (IIRC)
Once upon a time... (Score:4, Funny)
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!"
Proposed name: (Score:2)
Will the common APIs solve... (Score:3, Interesting)
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?
Security Risk or not, About TIME (Score:2)
Re: (Score:2)
Nothing wrong with that. (Score:3, Insightful)
Like, maybe we can get one mail client that's really good, instead of two half-baked ones, etc.
Re: (Score:3, Informative)
Re:Nothing wrong with that. (Score:5, Funny)
Re:Nothing wrong with that. (Score:5, Funny)
The Portland API will have an option to turn on more options.
Re:Nothing wrong with that. (Score:4, Funny)
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.
So how's that speech-recognition software test coming?
Re: (Score:3, Insightful)
Okay, so the last one was a made up example.
Re: (Score:2)
Azureus?
"55MB of Mono runtime to use an ID3 tag editor"
Banshee? (ignore the media playing part, please)
"30 Python libraries for the volume control dial"
Uh... Ok not a clue on this one.
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
Why not one mail client that's really good, and runs nicely in both, maybe even all desktops? I'd like it a lot if reasonable parts of the API's for different desktops were merged, but I really hope the desktops remain separate, and to be honest given the nature of open source licences, I can't see how there ever could be one definitive monolithic open source desktop unless it miraculously gave everyone everyth
Re: (Score:2)
Why not one mail client that's really good, and runs nicely in both, maybe even all desktops?
One good mail client? True, since Thunderbird hasn't gotten the same market share as Firefox, this seems to be necessary.
On all desktops? This would mean also on Windows and Macs which implies you have to start anew using wxWidgets (and possibly wyoGuide http://wyoguide.sf.net/ [sf.net]). Yet I think there's nobody out there who do
Re: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:2)
By "widget set" are you referring to the way the widgets you see on the screen appear and behave, or to the actual toolkit (GTK+/Qt/etc.) and higher-level (GNOME/KDE/etc.) APIs?
If the latter, the APIs definitely will notbe identical. If the former, they still won't be identical; GTK+ and Qt and... will still exist, it's just that certain desktop environment operations that involve data outside the applicat
Re: (Score:2)
according to the interview the portland tools where developed with feedback from what kept COMMERCIAL vendors back from entering the linux market.
the target audience is nog kde or gnome application writers, those people should write programs simple the way kde or gnome does things.
I feel cheated. (Score:2, Funny)
Think of how many more +5 Funny's we would have had.
Re: (Score:2)
Re: (Score:2)
Linux == freedom == lack of unity. It's simply a fact of life.
Re: (Score:2, Insightful)
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.
Re: (Score:2)
Perhaps, but a third popular desktop platform [apple.com] has two of them - Carbon and Cocoa. (I assume Windows is one of the two; what's the other one?)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
I'm tired of whiners... (Score:2, Insightful)
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
Re: (Score:3, Insightful)
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'
It's not about combining Gnome and KDE (Score:3, Insightful)
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 use
I'd rather have lots of interfaces (Score:2)
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 th
Re: (Score:2)
Sure, but wouldn't it be great if you only had one set of libraries to deal with? In other words, you could choose whatever look-and-feel you wanted, but all your apps would be the same under the hood? I know that I get annoyed when I try to use non-GTK apps in K
Re: (Score:2)
Absolutely. I'm all for abstracting the API's to make it easier for developers to write apps that'll work well in more places. I'm saying this as a developer, although not someone who spends a lot of time with GUI programming (apart from what I have to for my Windows-coding job). I just don't like the idea of combining the UI into one big project in a way that might make it harder to get diversity and choice for users. To me, that just represents the whole Windows, monolithic, Microsoft-and-nobody-else-
Re: (Score:2)
I'm all for abstracting the API's to make it easier for developers to write apps that'll work well in more places.
Let's say I agree with this.
I just don't like the idea of combining the UI into one big project in a way that might make it harder to get diversity and choice for users.
Well - that's the problem, no? If it isn't "one big project" then it's going to be "a dozen small projects". And whenever someone doesn't like something, they'll for their own version and their own way of doing things becau
Re: (Score:2)
This is exactly right, and I can appreciate everything you've said. I suppose my concern is with the implication that it should be up to the "open source community" to change things. This is partly because it's never
Re: (Score:2)
Perhaps for some people, the icon graphics and the location of items on the menus might be critically important, and I guess that's my point.
There are all sorts of reasons that people prefer Gnome over KDE [google.co.nz], or KDE over Gnome. Some people (like me) like completely different interfaces from time to time, if only to get away from the whole panel on the bottom and menu on the left for a while. Sometimes it's a speed issue, it might be where and how much customisation they want, it could be a whole lot of thi
Re:Help me understand (Score:5, Funny)
Preference would have to be Kate over Roseanne (Score:3, Funny)
Re: (Score:2)
No, because that's just a window manager, not a full desktop environment. Perhaps you meant to say "You mean, like, CDE?"
Re: (Score:3, Informative)
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 [freedesktop.org] lists XFCE as another probable supported desktop environment.
Re: (Score:2)
Re: (Score:2)
I miss old-school enlightenment [slashdot.org].
Re: (Score:2)
When all you have is a hammer (Score:2)
I beg to differ (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Windomaker isn't dead. (Score:2)
oops (Score:2)
Re: (Score:2)
Re: (Score:2, Interesting)
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
Re: (Score:3, Informative)
Re: (Score:2)