Waldo Bastian: 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.
Rayiner Hashem: 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.
Waldo Bastian: 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.
Rayiner Hashem: 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?
Waldo Bastian: 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.
Rayiner Hashem: 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?
Waldo Bastian: 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.
Rayiner Hashem: 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?
Waldo Bastian: "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.
Eugenia Loli-Queru: 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?
Waldo Bastian: 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!)