Submitted by The Open Source Development Labs and Freedesktop.org announced the 1.0 release of the Portland common desktop interfaces today, less than a year after work started on the project. Portland was conceived last year at the first Desktop Architects Meeting in Portland, as a way of making it easier for ISVs to write applications for Linux.
I hope it sticks and doesnt go the way of united linux..
also interesting to note that ubuntu arnt on the list though..
also interesting to note that ubuntu arnt on the list though
xdg-utils is already part of Debian tesing and unstable, so I guess it is in Ubuntu as well.
If version 1.0 makes it into the next Edgy Eft is however a different issue.
WindowMaker and FVWM?
WindowMaker and FVWM?
If those systems actually provide the necessary infrastructure, e.g. central settings for preferred applications and an assoicated commandline tool, there will be no problem integrating respective code paths.
But as far as I know the two are just window managers without desktop environment framework
Well, yeah, although WindowMaker is often used with GNUStep.
http://www.gnustep.org
Edited 2006-10-12 12:50
“He also says that “we have confirmation” that ATI is moving towards opening up its capabilities for video drivers since the company’s acquisition by AMD”
I may have missed this already, but that seems like the real news to me here.
This surely can only be good!
Too bad that opening the native file/print/whatever dialog window from the inside of an app is stated only as a long term goal 🙁
Is that what it is? A common platform that takes API to the next level but without complete bloated virtualization like that of Java?
Or am I missing something?
http://neosmart.net/blog/archives/235
No, they are completely different. .Net is a huge set of libraries that tries to do just about anything you’d ever want to – just like Java. This is simply a small interface that provides a common base between different distributions/desktop environments.
Edited 2006-10-11 22:08
Childish jab at Java…a little .NOT bias maybe? Wrapping Win32 w/ a JIT-based VM…like JAVA isn’t bloat, however?
Interesting how I am able to use less ram w/ better responsiveness in Netbeans and Eclipse than I could w/ Visual Studio 2005?
But I digress…no, you missed something.
Perhaps that caused by all the missing features?
What you’re missing is that you’re talking about neither Java nor .NET, but of Inferno:
http://www.vitanuova.com/
There’s your common platform without bloat. What completely boggles me that people are not wildly enthusiast about *that*.
Of all things, why Linux?
Edited 2006-10-12 12:57
I do hope they mean writing applications for KDE and Gnome, not the OS as that’s usually not the desktop environment.
Well as long as it’s not graphical I think both can make use of it, their main goal is to make GNOME and KDE use more similar libraries, I think it’s a nice idea, and from what I heard KDE is going to use more and more portland stuff, now let’s hope GNOME follows. As long as the two have their own different UI and way of working, using similar libraries under the hood can be a benifit for both.
I do hope they mean writing applications for KDE and Gnome, not the OS as that’s usually not the desktop environment.
As far as I know there are no OS specific things in our code and if there are we are not rejecting patched to fix that.
The press release is mainly focusing on Linux because the target audience, i.e. independent software developers, are currently interested in “Linux” solutions.
…is this going to be some sort of shared wrapper library? Or would KDE and GNOME people write their own set of APIs that match?
I know one more item on the call stack is not a big deal, but with the UI’s becoming more complex and more graphical and dynamic, any little bit of extra code or time spent pushing and popping all sorts of junk just doesn’t seem worth it. Pick a UI and be happy with its suite.
…is this going to be some sort of shared wrapper library? Or would KDE and GNOME people write their own set of APIs that match?
The next step, DAPI, will be a library on the application side, as well as set of D-Bus interfaces on the desktop side, which in turn can be implemented by the desktop environments usual service infrastructure or by additional “adapters”.
The second approach is more likely the one used for older/current versions of the desktops, while directly implementing the interfaces will be more likely used for future versions