Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×

Common Interfaces for Gnome and KDE Released 186

Posted by ScuttleMonkey from the hitting-the-adoption-gas-pedal dept.
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.'"
This discussion has been archived. No new comments can be posted.

Common Interfaces for Gnome and KDE Released More

Common Interfaces for Gnome and KDE Released

Comments Filter:

  • Comment removed (Score:4, Insightful)

    by account_deleted ( 4530225 ) on Wednesday October 11, 2006 @05:17PM (#16399953)
    Comment removed based on user account deletion

    • The danger for developers (Score:4, Insightful)

      by KingSkippus ( 799657 ) * on Wednesday October 11, 2006 @05:51PM (#16400441) Homepage Journal

      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)

        by Bastian ( 66383 )
        Right. This only makes sense from any standpoint if Portland replaces the existing interfaces in KDE and GNOME. But of course that can't be done right away because there are too many apps that rely on them.

        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)

          by Si ( 9816 )

          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)

            by Bastian ( 66383 )
            You do realize that, despite a lot of pedantic noise made by a few people like RMS, the word "Linux" is commonly used as shorthand for an entire family of operating systems based on the Linux kernel, and that for most everybody concerned the desktop environment is an integral part of any Linux install for workstation and desktop computers?

            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)

              by ozmanjusri ( 601766 )
              Which means I have reason to think you understand what I was say and know that your response is pretty well beside the point.

              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)

      • More like, we have developers developing for one platform, and then package maintainers listing desktop environments as dependencies for a simple media player.

        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

    • 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.

      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

    • "If it's not already in your development tree or toolkit, xdg-utils is available for download at http://portland.freedesktop.org/wiki/ [freedesktop.org]. "

      The great thing about standards is there are so many to choose from...

    • Re:The danger for users (Score:5, Insightful)

      by Grishnakh ( 216268 ) on Wednesday October 11, 2006 @07:19PM (#16401477)
      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.

      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.
  • 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

    • Re:Dbus for Windows? (Score:5, Informative)

      by parvenu74 ( 310712 ) on Wednesday October 11, 2006 @05:33PM (#16400191)
      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.

    • Re:Dbus for Windows? (Score:4, Funny)

      by mabinogi ( 74033 ) on Wednesday October 11, 2006 @06:47PM (#16401149) Homepage
      > The strength of Windows in the corporate desktop is that everything is integrated together.

      Wow, I want the version of Windows you've got!
  • 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?

    • Comment removed (Score:4, Informative)

      by account_deleted ( 4530225 ) on Wednesday October 11, 2006 @05:33PM (#16400187)
      Comment removed based on user account deletion
    • Whatever the effort, something has to eventually unify the desktop environments for Linux to overtake or compete on a widescale in the United States or Canada. I can't understand what the point of diversity is, when average users complain that even one interface different from Windows confuses them and discourages them from taking up Linux. What's the point of muddying the option waters further? If it's all about shiny buttons and bells being in different places, at least make it so that the applications wo

      • Re: (Score:2)

        by Rix ( 54095 )
        Thats a lot of talk from someone who presumably isn't rolling up their sleeves to help.
        • You presume too much. I promote Linux as best I can, and routinely install different distributions on my computers to try them out. I ask questions on the respective help forums to give feedback, and attempt to convince developers of things I think are crucial to the uptake of Linux. I've seen good progress lately from Ubuntu - installing from a LiveCD GUI, so you can websurf and IM while you install Ubuntu! I didn't even think of that as a possibility. And now you don't have to mount an NTFS drive by hand,
      • Applications already work in either environment. Portland's goal is to make it even EASIER for the developers to make apps that work in ANY *nix environment.

      • Re: (Score:3, Insightful)

        by jesterzog ( 189797 )

        Whatever the effort, something has to eventually unify the desktop environments for Linux to overtake or compete on a widescale in the United States or Canada.

        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

        • "Linux is a kernel -- Windows is a Kernel and OS."

          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)

      by treke ( 62626 )
      Entirely different ideas. Redhat's approach had two major portions. First they had widget, icon, window manager themes for both KDE and GNOME that looked and behaved the same. On its own that really won't kill the native feel that much, just make them both look the same. The next thing they did was change the default config options of both desktops so that they had the same basic layouts, behavior, and application selections. That's the part that really makes them feel different. I ended up using the blue

    • Disguise vs. Translation (Score:5, Informative)

      by Kelson ( 129150 ) * on Wednesday October 11, 2006 @07:43PM (#16401797) Homepage Journal
      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.
  • 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.

  • Question (Score:2, Funny)

    by Anonymous Coward
    Wouldn't it be cool if you opened up "My Computer" and had a drive for every letter of the alphabet?
  • 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 u

    • Re: (Score:3, Insightful)

      by Josh Triplett ( 874994 )

      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.

      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

    • For KDE you can run 'kde-config --prefix' to find out where KDE is installed, so instead of writing '/opt/kde' you could put '`kde-config --prefix`' which would then replace it with where KDE is installed into. Also Portland's goal is to help solve some of those problems (not by standardizing the locations, but by giving you tools where you don't need to know the locations).
    • There's a bit more to it than interface philosophy. There are legal and performance and portability issues.


      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.
  • it'll also put the OK and Cancel buttons the right way around.

    Am I wrong or am I right?

    • Re:Hopefully (Score:5, Funny)

      by NamShubCMX ( 595740 ) on Wednesday October 11, 2006 @06:18PM (#16400791)
      I guess you meant are you right or are you wrong?

    • Re: (Score:3, Informative)

      by Guy Harris ( 3803 )

      it'll also put the OK and Cancel buttons the right way around.

      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)

    by rg3 ( 858575 ) on Wednesday October 11, 2006 @07:10PM (#16401381) Homepage
    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.

  • menus (Score:2)

    by hey ( 83763 )
    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.

  • Developers, not users (Score:3, Informative)

    by Rob Kaper ( 5960 ) on Wednesday October 11, 2006 @07:36PM (#16401715) Homepage
    Specifically, these tools make installing and uninstalling menus, icons, and icon-resources easier for developers

    Aha.

    Developers already have easy .desktop files for menus and application icons.

    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)

      by Kelson ( 129150 ) * on Wednesday October 11, 2006 @07:59PM (#16401975) Homepage Journal

      I think the next sentence is more important:

      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.

      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)

        by Rob Kaper ( 5960 )
        Point taken.

        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) .desktop properties.

  • Once upon a time... (Score:4, Funny)

    by dcapel ( 913969 ) on Wednesday October 11, 2006 @09:05PM (#16402659) Homepage
    I was walking across a bridge one day, and I saw a man standing on the edge, about to jump
    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 ... are you religious or atheist?"
    "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!"
  • XFPortland.

  • Will the common APIs solve... (Score:3, Interesting)

    by bogaboga ( 793279 ) on Wednesday October 11, 2006 @09:36PM (#16402911)
    Will the common APIs solve the fact that I cannot paste a PDF web URL in Evince in GNOME and have Evince load it? This is one of the things that keeps me from using GNOME.

    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?

  • 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.)

Slashdot Top Deals

UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn

Close