freedesktop.org interview for OSNews

Mon Nov 17 11:06:03 GMT 2003

It could always be better, but I think there is a healthy interest in what 
freedesktop.org is doing, and with time that interest seems to be growing.

> While it seems 
> that  there has been significant support for some things (the NETWM spec)
> there also  seems to be a lot of friction in other places. This is
> particularly evident for  things like the accessibility framework or glib
> that have a long GNOME history. 

I don't see the friction actually. KDE is not thrilled to use glib but nobody 
at freedesktop.org is pushing glib. It has been considered to use it for some 
things at some point and the conclusion was that that wouldn't be a good 
idea. The accessibility framework is a whole different story. KDE is working 
closely with Bill Haneman to get GNOME compatible accessibility support in 
KDE 4. Things are moving still a bit slow from our side, in part because we 
need to wait on Qt4 to get some of the needed support, but the future looks 
very good on that. TrollTech has made accessibility support a critical 
feature for the Qt4 release so we are very happy with their commitment to 
this. We will hopefully be able to show some demos in the near future.

> - What are the prospects for D-BUS on KDE? D-BUS overlaps a great deal with
> DCOP, but there seems to be a lot of resistance to the idea of replacing
> DCOP  with D-BUS.  If DCOP is not replacing D-BUS, are there any technical
> reasons you feel DCOP is better?

D-BUS is pretty much inspired by DCOP and being able to replace DCOP with D-
BUS is one of the design goals of D-BUS. Of course we need to look carefully 
how to integrate D-BUS in KDE, it will be a rather big change so it's not 
something we are going to do in the KDE 3.x series. That said, with KDE 3.2 
heading for release early next year, we will start talking more and more 
about KDE 4 and KDE 4 will be a good point to switch to D-BUS. Even though 
KDE 4 is a major release, it will still be important to keep compatibility 
with DCOP as much as possible, so that's something that will need a lot of 
attention.

> - What do you think of Havoc Pennington's idea to subsume more things into
> freedesktop.org like a unified MIME associations and a VFS framework? What
> inpact do you think KDE technologies like KIO will have in design of the
> resulting framework?

I think those ideas are spot on. The unified MIME associations didn't make it 
in time for KDE 3.2, but I hope to get that implemented in the next KDE 
release. Sharing a VFS framework will be somewhat more difficult Since the 
functionality that KIO offers is quite complex it may not really be feasible 
to fold that all in a common layer. What would be feasible is to take a basic 
subset of functionality common to both VFS and KIO and standardize an 
interface for that. The goal would then be to give applications the 
possibility to fall-back to the other technology with some degradation of 
service in case a specific scheme (e.g. http, ftp, ldap) is not available via 
the native framework. That would also be useful for third party applications 
that do not want to link against VFS or KIO.

> - A lot of the issues with the performance of X11 GUIs has been tracked
> down to applications that don't properly use X. We've heard a lot about
> what applications should do to increase the performance of the system
> (handling expose events better, etc). From the KDE side, what do you think
> the X server should do to make it easier to write fast applications?

"fast applications" is always a bit difficult term. Everyone wants fast 
applications but it's not always clear what it means in technical terms. 
Delays or lag in rendering is often perceived as "slow" and a more agressive 
approach to buffering in the server can help a lot in that area. 

I myself noticed that the server-side font-handling tends to cause slow-down 
in the startup of KDE applications. Xft should have brought improvements 
there, although I haven't looked into that recently.

Other KDE developers may have better examples.

> - If QT changes are required to confront with changes needed for
> interoperation with GTK+ or Java or other toolkits, is TrollTech keen on
> complying? If KDE developers do the work required is TrollTech keen on
> applying these patches on their default X11 tree?

TrollTech is overall quite responsive to patches, whatever their nature, but 
in some cases it takes a bit longer than we would like to get them into a Qt 
release. That said, we have the same problem in KDE where we sometimes have 
patches sitting in our bug-database that take quite long before they get 
applied (Sorry BR62425!)

Cheers,
Waldo
- -- 
bastian at kde.org -=|[ SUSE, The Linux Desktop Experts ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/uKubN4pvrENfboIRAgqEAKCOP6VQ5kA6KtQJBQimT6lqPNTS3wCeMfqK
HPijxt9q/7H14KMG6qjitjg=
=SKgS
-----END PGP SIGNATURE-----