Over the past week, some of the Linux desktop’s foremost developers gathered together in Portland, Oregon at the OSDL (Open Source Development Labs) Desktop Architects Meeting to work further on bringing order to the Linux desktop. According to John Cherry, the OSDL‘s Desktop Linux initiative manager, there was a good turnout of about 45 developers from the community, including major Linux vendors such as Novell and Red Hat, and ISVs (independent software vendors) like Google and Adobe.
It was the ISVs, according to Cherry, who had a strong and clear message for the Linux distributors: “Application vendors, esp. those like Google that distribute their software through the Web, and not necessarily bundled with a distribution, want to be able to count on any distro. continuing to keep and not depreciate or eliminate software libraries.”
Cherry explained, “They want to be able to count on libraries being there so that they don’t need to release a slightly different version for each distribution or each dot upgrade of a distribution.” In short, “They want to be able to release a Google Earth just once.” This message came across, “very clearly.”
As another part of this, the ISVs also want stable, consistent interfaces. How stable? They don’t want any interface to be obsoleted.
At a breakout session, these matters were talked about further. It was decided that a survey should be made of exactly what libraries and APIs are being used by ISVs. This information could then be converted into a platform that ISVs and Linux distributors could commit to supporting.
Everyone at the meeting was also concerned about the remarkably murky area of Linux audio support. As one anonymous developer put it, “Audio on Linux sucks.”
In the area of audio, there was a laundry list of problems. Most agreed that there is no clear vision from anyone — kernel, distro, or application developers — on how to handle audio in Linux. Making matters even worse, there’s no venue to discuss audio problems, and what consumers want from audio is not the same thing as what an audio professional wants.
What exactly are the problems? The list includes, CODECs, configuration, how to handle multiple applications competing for the same hardware device, and a lack of APIs (application programming interfaces).
It was decided to start addressing these issues by creating a focus group and mailing a list of what’s needed from audio APIs, and how to deal with bringing consistency to Linux audio.
The issue of hardware drivers in general, always an area of concern in Linux, was also discussed. It was decided to create a kit for assessing platforms for their driver support and Linux compatibility. It was also noted that there’s a business opportunity for an entity to manage IHV (independent hardware vendor) drivers.
As Cherry said before the developer meeting, though, there are no perfect answers for hardware support in Linux, so long as vendors keep interface and device driver details proprietary.
At the conference, there was also, according to Cherry, “A great deal of interest in DAPI (Desktop Application Programming Interface).” In particular, the printer IHVs were very interested in getting DAPI out as soon as possible for print dialogs.
DAPI will be built on top of D-Bus. This, in turn, supplies both a system daemon and a per-user-login-session daemon. So, for example, a D-Bus system daemon can provide a single common way for any Linux desktop to check for when a new CD or DVD is placed in a drive.
D-Bus, itself, is rapidly being adopted by Linux desktop developers. KDE, in particular, is well on its way to moving from its existing IPC (interprocess communication) system to D-Bus for its next major version, KDE 4.
There will be a preview release of DAPI by January, 2007. If all goes well, the first release, DAPI 1.0, will be out by June, 2007. Everyone at the meeting pretty much supports D-Bus and DAPI. In particular, the ISVs would like to see D-Bus universally supported across distributions and, for that matter, operating systems. The D-Bus team, in turn, promised that they’d maintain backwards compatibility so that application vendors can feel comfortable making it their default IPC.
In the related issue of the Portland Project xdg-utils, a common set of APIs for KDE, GNOME, or any other Linux desktop environment, work is progressing on increasing its utility. A terminal emulator, xdg-terminal, is already in the xdg-utils CVS (Concurrent Versions System). Also in the works are a file manager context menu, a set/query default mail/browser/terminal/file manager, a General way to access “protocolhandlers” and Autostart. These should appear in the next version 1.1, in April, 2007.
Looking down the road, xdg-utils 1.5 will appear in July, 2007. By that time, prototypes will be available for both the Gtk and Qt Toolkits, and for the GNOME and KDE desktops.
The end result of all this desktop plumbing standardization will be Linux desktops and applications that, by the third quarter of 2007, should have a far more consistent look and feel across distributions and between KDE and GNOME. Thus, both users and software vendors should find Linux to be a far more friendly and inviting desktop.