Six months ago, architects from two dozen desktop-oriented Linux projects gathered in Portland, Ore. to work together on creating the best possible Linux desktop. Thus was born the Portland Project. Now, in Mainz, Germany, the expanded group is meeting again on May 8 and 9 to see how far it's come and to look at what's ahead.
Unlike many such collaborative efforts, such as the tangle of conflicts that are bedeviling the 802.11n wireless standard, the Portland Project is moving smoothly forward with its goal of creating a common set of standards that allow applications and desktop interfaces to easily integrate into an easy-to-use Linux desktop.
In his status report to the OSDL Open Source Development Labs-sponsored group, Waldo Bastian, Linux client architect at Intel, opened by covering the four areas that the developer felt needed the most improvement.
These are:
- Increased binary compatibility between distributions
- Increased compatibility between the two major desktop environments (GNOME, KDE)
- Making cross-distribution packaging easier for third party developers
- Improving documentation
Separating toolkit from runtime a key factor
Another part of this is to decouple the development toolkit from runtime environment. In other words, a user shouldn't need to run KDE to use a KDE application, or GNOME to use a GNOME application. They should be given a choice, but in such a way that it doesn't fragment the desktop into two different, warring desktop camps.
To address these concerns, Portland needs to provide a set of common high-level desktop-integration APIs (application programming interfaces). Much of that functionality is already available. For example, you can run the GNOME-based email and groupware client Evolution on a KDE desktop. But there are sometimes slight differences between GNOME and KDE, which are poorly documented.
In the short term, to make applications more compatible between the two platforms, the documentation needs to be improved to make it easier to write compatible applications.
Beyond that, the Portland project has provided xdg-utils, which are usable on top of existing deployed distributions. Xdg-utils is a set of common scripts, which provide a minimum level of compatibility for any Linux desktop.
In the first draft, these include...
- Installation:
- xdg-menu -- command line tool for (un)installing desktop menu items
- xdg-desktop -- command line tool for (un)installing icons to the desktop
- xdg-menu -- command line tool for (un)installing desktop menu items
- Runtime:
- xdg-email -- command line tool for sending mail using the user's preferred email composer
- xdg-mime -- command line tool for providing information about file type handling
- xdg-su -- run a program as root after prompting for the root password
- xdg-open -- opens a file or URL in the user's preferred application
- xdg-copy -- command line tool for copying files between desktop URIs
- xdg-file-dialog -- command line tool for providing file and directory selection dialogs
- xdg-email -- command line tool for sending mail using the user's preferred email composer
- Still To Do:
- xdg-icon -- command line tool for (un)installing icon files
- xdg-autostart -- command line tool for (un)registering applications for launch at startup
- xdg-mime -- add (un)installation of mime type descriptions
- xdg-icon -- command line tool for (un)installing icon files
Is xdg-su the correct approach?
There's also some question as to whether xdg-su is the right approach. You can probably expect to see xdg-su disappear, to be replaced with commands with finer permissions and control granularity.
After xdg-utils is more fully developed, it will be included in the 2007 LSB (Linux Standard Base) Desktop standard.
Looking further down the road, "DAPI (Desktop API) may require changes in upstream desktop projects," observed Bastain.
DAPI is made up of a daemon and an application library. When an application needs to interact with the desktop, it calls on the library, which in turn uses IPC (interprocess communications) to call the daemon. The daemon then orders the desktop to produce the expected result. So, for example, by using DAPI, an application doesn't need to "know" about the desktop environment. The program simply calls on the library, which with the daemon will produce the appropriate GNOME or KDE result.
DAPI still needs more work, though. It currently uses a custom IPC protocol, and Bastain believes that it "should probably use DBUS instead." DBUS is a simple IPC that's already available in Debian, among other distributions.
Bastain made the point that "the value of Portland is its definition of interfaces." Software vendors can differentiate by providing enhanced implementations of the service behind the interface.
Again, "even though both GNOME and KDE provide most functionality today already, documentation is lacking. Windows ISVs (independent software vendors) that want to enter Linux market cannot find the information they need. This should be dead easy."
To help make that happen, reference implementation will be provided "to allow a smooth adoption curve." Thus, "ISVs can use Portland today by including it with their application."
This summer, end-users will start getting a chance to see Portland in action as it will make its first appearance in Fedora, OpenSUSE, and Ubuntu. Bastain expects to see the first programs using Portland functionality this fall.
What may be ahead for the project
Moving ahead, Portland may be addressing controlling which proxy should be used for Web connections, a way to change the default application, a common print dialog for all applications, and a common way of managing certificate and passwords.
The printing issues are already being addressed by the Portland printing group.
As the vendors and open-source groups continue to smoothly work together on the Linux desktop's infrastructure, the ideal of a Linux desktop that's as easy to use and write software for as Windows is coming closer to reality.
-- Steven J. Vaughan-Nichols
没有评论:
发表评论