Author: Joe 'Zonker' Brockmeier
Waldo Bastian, OSDL’s Desktop Linux (DTL) tech board chairman, says that Portland will help solve the problem for ISVs of keeping “track of the peculiarities of 20 or so different distributions.”
For users, Bastian says that Portland means that applications from ISVs will “show up in their menu where they expect it to show up, show all of its files in the file manager like you would expect, and is able to use the email [application] and Web browser that the user has chosen to work with.”
Portland consists of a collection of command-line tools called xdg-utils and the Desktop API (DAPI). Xdg-utils includes several commands for performing functions like installation and removal of desktop icons and menu items, opening a file or URL in a user-specified application, and sending an email using a user’s preferred browser.
DAPI provides a library that can be linked to by ISVs that will allow applications to communicate with a desktop environment daemon to manage addressbooks, send mail, manage the screensaver, and perform other common tasks.
Though Portland 1.0 is just now being released, it has already been spotted in the wild. John Cherry, DTL initiative manager, says that CodeWeavers is using Portland tools in its applications, and Google made use of the Portland tools in its release of Google Earth for Linux.
OSDL also says that Portland is being used now in Debian, Fedora, and openSUSE, and Xandros and Red Flag have announced that the Portland tools will be present in upcoming releases.
The roadmap for Portland
The Portland 1.0 release is not the end of the road. The Portland developers have a number of features that they’d like to address. Cherry says that features for the next Portland release, and its timeframe, will be discussed at the third Desktop Architects meeting, which will take place December 7 and 8 at the OSDL offices in Portland.
At the first DAM, attendees identified the three biggest problems for Linux desktop deployment as support for developers and ISVs, hardware support via open drivers, and community coordination. Cherry says that Portland 1.0 is part of the answer to making it easier for developers and ISVs to target the Linux desktop, rather than having to worry about targeting KDE and GNOME separately.
As for open driver support, Cherry says that things have gotten better in the last year, particularly with improved support for wireless devices and better support for video cards. 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.
It’s also clear that community groups, through freedesktop.org and other mechanisms, are placing an enhanced emphasis on working together so that ISVs and developers can write applications for the Linux desktop. Bastian says that the “initial focus” for Portland is KDE and GNOME, but the group has also received several contributions to improve Xfce support as well.
With progress being made on the top three priorities raised last year, Cherry says that a “hot topic” this year will be “support for the iPod generation” in terms of support for multimedia, including support for proprietary codecs. Cherry pointed to Real Networks as a company making “great strides” in that area already.
Right now there is no hard and fast timeline for the next major version of Portland. Bastian pointed out that it is an open source project and its timeframe “depends heavily on the number of contributors.”
But Bastian also says that he expects a 1.1 version “in a few months” that will extend tools coverage to more distributions, and he hopes to include “additional contributions in that version to make the tools work better with environments such as Xfce and others.”
