

Rayiner Hashem: In your presentation at Nove Hrady, you point out that drag and drop still doesn't work as it should, mainly because of poor implementations. Are there plans for a drag-and-drop library to ease the implementation of XDND functionality?

Havoc Pennington Havoc Pennington: The issue isn't poor implementation in the libraries, it's simpler than that. When you add drag and drop to an application you have a list of types that you support dragging or dropping, such as "text/plain". Applications simply don't agree on what these types are.

So we need a registry of types documenting the type name and the format of the data transferred under that name. That's it.

The starting point is to go through GNOME, KDE, Mozilla,, etc. source code and document what types are already used.

The other issue requires even less explanation: application authors don't support DND in enough places.

Rayiner Hashem: Most of the examples listed in your Nove Hrady presentation were desktop level. Yet, you mentioned GTK+ 3 and Qt 4 as well. Do you think more interoperation at the toolkit level is necessary? What form would this interoperation take?

Havoc Pennington: I don't really think of as an interoperability effort anymore. Rather, it's an effort to build a base desktop platform that desktops can build on.

Many of the things on would be implemented in or used by the toolkit: icon themes, XEMBED, X server, Cairo, startup notification, and so forth.

Rayiner Hashem: From your experience with GTK+, what do you think are some of the properties that make it hard to write fast applications for X11? What would you like to see the server do to make it easier to write fast client applications?

Havoc Pennington: Talking only about speed (fast vs. slow) won't lead to understanding of the problem. Graphics will look bad if you have flicker, tearing, OR slowness. Most users will perceive all of those problems as "slowness."

Eliminating the round trip to clients to handle expose events will probably be a huge improvement in terms of both flicker and speed. The proposed Composite extension also allows double buffering the entire screen, which should let us fix virtually all flicker and tearing issues.

Some clients right now do things that are just stupid; for example, allocating huge pixmaps (image buffers) and keeping them around; improved profiling tools should help track down and fix these mistakes.

Eugenia Loli-Queru: Is working towards a package management standard? While RPM and DEBs are well known, what is your opinion on

Havoc Pennington: I don't really understand the motivation for autopackage. At their core, RPM and DEB are a tarball-like archive with some metadata. You can always just ignore the metadata, or add additional/different metadata.

For example, file dependencies; if you don't want your RPM package to have file dependencies, you don't have to include any.

I would tend to focus more on the question of which metadata we should have, and how it should be used by the installer UI.

autopackage tries to solve the problem that distributions use different packaging systems by creating an additional packaging system and using it in addition to the native one. However, you could just as easily pick one of the current systems (RPM, etc.) and use it on any distribution. RPM works fine on Solaris for example. I don't see how autopackage uniquely enables portability.

In short, to me the issues with software installation are not related to the on-disk format for archiving the binaries and metadata. I think autopackage could achieve much more by building stuff _around_ RPM and/or DEB rather than reinventing the archive wheel.

I haven't looked at autopackage in detail though, and I could be totally wrong.

Eugenia Loli-Queru: How do you feel about becoming an "umbrella" project for all projects that require communication (e.g. if X requires a kernel extension, makes sure that the X group is heard from the kernel group and manages the implementation)

Havoc Pennington: Ultimately can't make sure of anything; it's not an enforcement agency. What it can do is provide a forum that's well-known where people can go and find the right developers to talk to about a particular issue.

Implementation will really always come from the work and leadership of the developers who put in hours to make things happen.

Eugenia Loli-Queru: How do you grade the support of commercial entities towards Is IBM, Novell, Red Hat and other big Linux players helping out the cause?

Havoc Pennington: Individual developers from all those companies are involved, but there's no framework for corporations to get involved as corporations. I'm happy overall that the right people are involved. But of course I'd always like to see more developers added to the Linux desktop effort.

Eugenia Loli-Queru: In the plans of do we only find interoperation resolutions between DEs or innovation is part of the plan? For example, would welcome Seth Nickell's Storage or 'System Services' projects which are pretty "out of the ordinary" kind of projects?

Havoc Pennington at a KDE conference Havoc Pennington: I'd like to see more work originate at, and certainly we'd be willing to host Seth's work. Ultimately though any new innovation has to be adopted by the desktops such as GNOME and KDE, and the distributions, to become a de facto reality. may be the forum where those groups meet to agree on what to do, but doesn't have a "mind of its own" so much.

Eugenia Loli-Queru: In your opinion, which is the hardest step to take in the road ahead for full interoperability between DEs? How far are we from the realization of this step?

Havoc Pennington: I think the "URI namespace" or "virtual file system" issue is the ugliest problem right now. It bleeds into other things, such as MIME associations and WinFS-like functionality. It's technically very challenging to resolve this issue, and the impact of leaving it unresolved is fairly high. Here are some links on that here, here and here.

Eugenia Loli-Queru: On Mac OS X, users who require extra accessibility can listen to text from pretty much any application via text-to-speech, as it is supported in the toolkit level. Are there any plans on creating a unified way where all applications (Qt or GTK+) would be able to offer this functionality from a common library? What would be the best way to go about it? What accessibility projects you would like to see produced at

Havoc Pennington: This is already supported with ATK and the rest of the GNOME accessibility implementation, you can text-to-speech any text displayed via GTK+ today. I believe there's a plan for how to integrate Qt and Java into the same framework, but I'm not sure what the latest details are. This is looking like an interoperability success already, as everyone does appear to be using the same framework.

Eugenia Loli-Queru: I haven't found an obvious way to get Abiword, Gaim, Epiphany (granted, with the mozilla toolkit, but still one of the apps that begs for such accessibility feature) or Gedit to read any texts... How is this done then? Is it a compilation/link option? If yes, the problem is not really solved if it is not transparent to the user and if not get done automatically after a compilation.

Havoc Pennington: I haven't ever tried it out, but I've seen the a11y guys demo it. The toolkit functionality is definitely there, in any case. I think you go to Preferences -> Assistive Technology Support and check the screenreader box, but I don't know if it works out of box on any distributions yet. It's a new feature. (editor's note: "screenreader" on Fedora is greyed out, while on the latest Slackware can be selected, but it is later dumbed "unavailable" and so it doesn't work yet out of the box for most distros).

Table of contents
  1. "Havoc Pennington on"
  2. "Keith Packard on the new X Server"
  3. "Jim Gettys on the new X Server"
  4. "David Zeuthen on HAL"
  5. "Waldo Bastian on KDE/Qt and"
e p (0)    81 Comment(s)

Technology White Papers

See More