“Portland is a new open source project that promises to simplify the deployment and commercialization of Linux applications by helping them run on multiple desktop environments, including Gnome and KDE. Although still young, Portland is available today, and it looks to be improving rapidly. Get started using the XdgUtils toolset in Portland 1.0.”
Portland is anything but new. They have just hit 1.0 last october: I guess that want they want to say by “new”.
As I recall Portland project is part of LSB, let’s hope that the distros quickly make the xdg-util package part of the base installation.
As I recall Portland project is part of LSB, let’s hope that the distros quickly make the xdg-util package part of the base installation.
It’s tentatively scheduled for LSB 3.2, but that basically depends on whether the mainstream distros have packaged it. The question mark from what I last read was around whether or not Red Hat would be shipping it with RHEL 5 which would lead to inclusion in LSB 3.2; otherwise it will probably have to wait for 4.x.
Here’s a post from one of the KDE devs that was published a couple of months ago, it may give a better example of how xdg-utils can be used to tweak and better integrate existing applications with non-native desktops or setups. They can be useful utilities for users, as well.
http://www.kdedevelopers.org/node/2535
Neat, but this should become unnecessary for users in short order. Distros should just set all of the external handlers for DE-neutral apps to xdg-blah by default. Then the user can select preferred handlers through their DE’s configuration panels, rather than knowing XdgUtils even exists.
I’m very glad to see that Portland is happening and the initial code is already working well. I’m also happy that Portland 2.0 will provide the abstractions at the D-BUS level. D-BUS is turning out to be quite handy for implementing the “it just works” kind of features.
Distros should just set all of the external handlers for DE-neutral apps to xdg-blah by default.
Some of the distros even have extended their version of the scripts to include their previously used “adapters” in the generic fallback case, e.g. Debian’s xdg-open calls x-www-browser in the code branch that handles the “no DE detected” case.
The main question however is, will vendors of very common apps, e.g. Mozilla, use it, or will they stay as little integrated as possible.
that’s no body care that much about LSB and specially portland. I say that because the very little comments. I Think it’s primary for Linux advancement.
Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Google Wireless Transcoder;)
I fully agree.
I currently maintain the Fedora IceMW and Gmrun packages – both of which depend havily on xdg-utils.
Without it, generating menus and/or starting the default applications would have been a royal pain in the back side.
– Gilboa
Edited 2007-02-14 11:03
I know it’s not an X11-based desktop, but those utils used in makefiles & apps would save some work when porting and let ppl concentrate on the gui code.
xdg-open is quite easy as Zeta/Haiku has a similar open command already
The install time helper scripts now also get used or are being looked at in third party installers as mentioned in the comment section on linux.com
http://applications.linux.com/comments.pl?sid=37893&pid=95101&thres…
for the time when it will be possible to access to the native file, print and other dialogs of the running DE from any app – so that, say, Gimp opens KDE file dialog for saving a file, and Krita opens Gnome one. AFAIK Portland plans to implement that, but at some later stage.
Also, it would be nice to take over the seemingly abandoned, but once promising Metatheme project to implement a uniform look for all widget toolkits.
And of course, a unified, standard API for cross-distro package installation would be a most welcome addition.
For file dialogs, the xdg-utils repository already contains a script which just hasn’t been in the 1.0 release since the availabilty of zenity (used in case of GNOME and XFCE) can not be sufficiently expected.
Interesting! But is it really necessary to rely on zenity? I don’t think Portland needs all its capabilities and versatility to open several dialog windows. Also, a script is IMO not the optimal solution for opening a dialog window from an application such as Gimp or Krita.
But is it really necessary to rely on zenity? I don’t think Portland needs all its capabilities and versatility to open several dialog windows
If you know a better dialog program for GNOME/XFCE which can do file selection dialogs, we are interested in hearing about it.
Also, a script is IMO not the optimal solution for opening a dialog window from an application such as Gimp or Krita
Yes, true, the service based second phase will be more suitable for this, but I thought it can’t hurt to mention xdg-file-dialogs in case someone wants to do file related stuff in a script
If you know a better dialog program for GNOME/XFCE which can do file selection dialogs, we are interested in hearing about it.
Nah, I just think that the corresponding functionality should be implemented right within the Portland project – possibly by borrowing the relevant code from Zenity.
“for the time when it will be possible to access to the native file, print and other dialogs of the running DE from any app”
I would like to suggest to look into: (search kde-apps.org)
kgtk – for OVERRIDING the GTK open / save dialogs with KDE ones. (yes, Gimp, Inkscape, OpenOffice etc with KDE open / save dialog)
“Also, it would be nice to take over the seemingly abandoned, but once promising Metatheme project to implement a uniform look for all widget toolkits.”
gtk-qt-engine – for making ALL applications follow chosen KDE look.
I am not prescribing, but just suggesting that these are worthy, working tools for KDE-centric users.
kgtk – for OVERRIDING the GTK open / save dialogs with KDE ones. (yes, Gimp, Inkscape, OpenOffice etc with KDE open / save dialog)
This is cool, didn’t know about this proggie! But unfortunately, it’s not DE-agnostic.
gtk-qt-engine – for making ALL applications follow chosen KDE look.
Yeah, I knew about gtk-qt-engine, but IMO Metatheme created more uniform look. Also, Metatheme was toolkit-neutral right from the start.
Anyone care to mention software installation? *Ducks*
I think Portland could help out quite a bit here, and the DBUS interfaces could prove to be mighty useful for everyone.
Edited 2007-02-14 15:41