 | Level: Intermediate Cameron Laird, Vice president, Phaseit Inc.
13 Feb 2007 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.
When building a development plan for your desktop Linux application, you might reasonably ponder which desktop environment (DE) to target. Gnome or KDE? Certainly. Something else? Maybe.
But if you're only considering one desktop environment, you might be selling your
application short, given the progress of the Portland project.
The Portland project
First, a little background. The Portland project was hatched as a way to address a
number of nagging concerns that have made it difficult for software developers to write
applications that are easily portable to the various desktop environments (DEs) packaged
with all of the many Linux distributions. In particular, Portland's goal is to provide a common set of APIs that developers can write to that will make their applications DE-agnostic.
The first and currently implemented phase of the project, Portland 1.0, is a bundle of utilities called XdgUtils that you can run along with your applications on top of existing DEs. Plans for the second phase, Portland 2.0, involve a service-oriented interprocess communication approach based on D-Bus interfaces.
Portland currently supports KDE and Gnome, although XFCE, GNUStep, and MacOS X are being considered for the future.
In this article, you can get started with the XdgUtils part of Portland while getting some insights into how Portland's design reflects its broader goals.
Take a look at Listing 1, which shows the use of the xdg-email utility:
Listing 1. Example use of xdg-email
# This invocation is valid for all desktop
# environments and any e-mail client a user
# may prefer.
xdg-email --cc $COLLEAGUE --bcc $SELF \
--subject "Problem report" \
--body "This is a semi-automated fault report. You
can edit this e-mail before sending it.
Note that the problem log is automatically
attached." \
--attach $LOG errors@$OUR_HOME
|
Do you see the possibilities? This single command replaces pages of scripting that you might have done to accommodate a range of such e-mail clients as Firefox, elm, /bin/mail, Opera, and many, many more.
To make it easier to understand and make full use of such a command, here's a bit of
context: a DE consists of the window manager, icons, toolbars, applications, wallpaper, abilities (including drag and drop), and a distinctive look and feel that shapes your immediate experience as a desktop computer user. Common DEs include Gnome, KDE, XPde, ALDE, Xfce, and others. You want your programs to look "native" and operate well in the DEs you and your customers or colleagues use: cutting and pasting should happen immediately, your color palette mustn't crash your customers' screens, and a correct installation of your program should show up in a sensible location within the DE's application choice menus.
Until recently, the reliable way to achieve those ends was to work in and become familiar with the conventions of a specific DE -- KDE, for example -- then call in a specialist or relearn the practices required for each additional DE. At this level, the point rarely is to achieve special functionality or port the application in any sophisticated way; in principle, properly-installed Linux applications will display with any DE's window manager. It's just the fiddly details of installation, including the location of necessary libraries and sometimes minor graphical decorations, that distinguish the DEs.
Getting those details right is necessary, though, as you move beyond writing applications for yourself and a few other programmers to widely distributed and commercial products. Notice that I'm not looking at anything that end users would see as dramatic: Portland does not address the "sizzle" of GUI themes or shading effects or virtual file system innovations. Portland simply helps working developers code to a more rational interface when preparing installation and deployment automations.
A typical if mundane example, which you saw in Listing 1, is to prepare an e-mail message that the end user can edit in his or her chosen e-mail client. Portland defines the command xdg-email, which manages all the common tedium involved in such a task. Invocation of such a command line launches the user's e-mail client, populates its elements (cc: list, attachments, and so on), and turns over control to the end user. Do your applications need that kind of help? If so, Portland is for you.
Your first visit to Portland
The Portland utilities became publicly available only last year, but don't let that
discourage you: It's a project that seems to be consistently hitting its goals, and it's certainly useful even in its current version. It still lacks detailed tutorials and some other standard conveniences.
To start with Portland, retrieve sources with anonymous CVS:
cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/portland \
co portland/xdg-utils
This downloads a collection of command-line tools, XdgUtils, along with a preliminary test
plan, the beginning of a test suite, a basic installer, HTMLized manual pages, and a few
administrative files. Documentation and other refinements will eventually join these.
Portland also collects C bindings, called desktop API (DAPI).
You'll get a peek at DAPI in the next section.
XdgUtils includes tools to:
- Install and uninstall desktop icons, icon resources, and menu items
- Prepare e-mail using a user's preferred composer or mail user agent
- Query and manage file types (.gif, .c, and so on) and their descriptions
- Open a file or URL in an appropriate application selected by the user (just like
command-line
start in Windows® or open in Mac OS X)
- Control the screensaver
- Elevate the permissions of a program in a consistent and safe way
These tools should be accessible to developers working in any language or development environment; they can be invoked programmatically just like any other command available in the shell. If you're working in Python, for example, you might use one of the XdgUtils tools either in a bash-code installation script, or with a system call, like so:
os.system("xdg-open %s" % chosen_URL)
Or, you could use any of Python's other functions for finer control of an external process.
At first glance, then, Portland has quite modest goals. It just wraps existing functionality -- installation of icons, management of the screensaver -- in a consistent way, so we developers don't have to recreate all the basics for each new application or DE we're assigned. And it does so inexpensively: Portland's open source license makes it available without money cost, and its simplicity makes it cheap in time to download, install, and use. The obvious conclusion is that you get a definite and significant payoff for a small investment. That's an easy choice to make.
Bright prospects
It's a particularly easy choice if you believe that Portland is likely to grow from here. For the initial release, most effort has gone to Linux-based Gnome and KDE, with Xfce also getting what Intel Corp.'s Linux client architect Waldo Bastian, a leading Portland contributor, calls "much attention." Once Portland is through its first round of successful application, though, it's natural to anticipate its spread to more DEs, and even other operating systems, such as Solaris or FreeBSD. Its command-line implementations certainly lend themselves to extension to new domains. From my perspective as a development manager, I'm happy to code to the Portland interfaces. If one of our customers requires porting to a DE that Portland doesn't already support, it'll be no harder for us to implement a proper Portland extension than it would be to adapt our own code to the unsupported DE.
And the situation should only improve as time goes on. If the current implementation becomes as popular as I expect it will, vendors, including distribution packagers, will have it in their interest to maintain and update the Portland parts, and especially to adapt them in OS-specific ways. At the same time, the Portland team is committed to unchanging programmatic interfaces. The test suite prepared by Intel's Tom Whipple should help guarantee this stability.
Several open questions remain around Portland. The whole topic of packaging standards remains to be negotiated. Portland planners wisely decouple their architectural decisions as much as possible; for now, packaging issues have been isolated, and it's not even known yet whether their eventual resolution will be part of Portland, Linux Standard Base (LSB), or some other effort. For now, Portland remains narrowly focused on programmatic access to icons and other components of a typical window manager. Once KDE 4 appears, the programming interface will likely expand to include icon naming and shared MIME database specifications.
Keep in mind that you can have that window manager-level access in-process using the C bindings called DAPI, if you prefer. While XdgUtils is more mature, you can retrieve an early release of DAPI through the project's CVS repository:
cvs -d :pserver:anoncvs@cvs.freedesktop.org:/cvs/portland \
co portland/dapi
Effective DAPI coding can be either blocking or event-oriented. In the latter case, an application connects to DAPI, then listens for activity in the style of select(). An example of a blocking call is the function to open a resource in Listing 2, slightly modified from the distribution documentation.
Listing 2. Example DAPI C code for opening a URL
/* Initialize with dapi_connectAndInit(). */
static DapiConnection* my_dapi_connection;
int openURL(const char *url)
{
/* DAPI wants to know about toplevel_widget so
it can properly handle focus, layering, ... */
if (dapi_OpenUrl_window(my_dapi_connection,
url,
XWINDOW_HANDLE(toplevel_widget)))
return 1;
/* Handle failure here ... */
}
|
Summary
If your application, and particularly its installer, addresses a DE directly, Portland gives you a better way to achieve the same result. With minimal source changes, license impact, or programming difficulty, and no sacrifice in functionality, you can switch to reliance on Portland and gain portability that is a multiple of what you could achieve on your own. You'll also be in position to leverage any enhancements and expansions to Portland that might be coming up in the future.
Resources Learn
Get products and technologies
-
Portland also gives WebCVS
views that allow browsing of individual files and their revisions, along with the CVS access mentioned above,
-
freedesktop.org and OSDL are two key actors
in the Portland project. OSDL and the Free Standards Group merged recently to form The Linux Foundation.
-
Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
-
With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.
Discuss
About the author | 
| | Cameron Laird is a long-time developerWorks contributor and former columnist. He often writes about the open source projects that accelerate development of his employer's applications, focused on reliability and security. |
Rate this page
| |
