KDE Development News

This report is part 1 of 2, covering the month of October. Part 2, when available, will be an overview of the usual mailing-list material.

Despite the dearth of reports on my side, there has been furious development activity and some major architectural changes in KDE over the past month. A technology overview by Mosfet is also available; overlaps in the material presented here were unintentional but harmless.

KParts (aka Canossa) is the new replacement for OpenParts, the previous CORBA-based mechanism for embedding one application in another. Unlike OpenParts, KParts is optimized for use on the local desktop and is based on a purely C++/shared-library approach. KParts is not a replacement for CORBA, it simply replaces CORBA for the particular task of embedding one application in another -- something which CORBA was not designed to do.

For developers, KParts is simpler and much easier to use; compile time has also been significantly improved. Users enjoy a less bloated enviroment as well as speed and stability improvements. KParts has already proven itself to be a big hit -- KOffice parts and friends were almost completely ported in a matter of days.

DCOP (Desktop Communication Protocol) is a new lightweight and fast IPC/RPC mechanism based on X's standard ICE (Inter-Client Exchange) protocol. It is meant to unify previous IPC mechanisms such as KDE 1's kwmcom and various other hacks. DCOP is simple, small and efficient and is consequently much better suited to the task of IPC than CORBA (which was not really designed for this task). All KDE applications are linked against the DCOP library and so can communicate efficiently and easily as required. Preston Brown has already implemented a KUniqueApplication feature through some DCOP magic.

Developing optimally for KDE2 no longer requires being a CORBA expert, although the CORBA-based KOM (KDE Object Model) is still available for distributed applications. It is perhaps quite important that the distinction between local and distributed applications be made in this manner, as outlined by this interesting paper from Sun Microsystems (gzip and postscript viewer required). The bottom line: writing a distributed application is *hard* and blurring the distinction with local applications is not desireable.

But what about interoperability? While DCOP is based on the standard ICE protocol, the streaming protocol used still needs to be implemented by non-KDE/Qt applications. Although a direct approach is possible (such as Richard Moore's ongoing port to Java), Kurt Granroth sidestepped the issue completely by implementing an XML-RPC <--> DCOP bridge. What this means is that any platform or language that can do XML and HTTP can now communicate with, control or script KDE applications. Alternately, DCOP applications should be able to communicate with XML-RPC applications, including those running on Redmondian OSes.

A CORBA wrapper for KParts and DCOP is also possible, and would enable interaction with other environments such as GNOME.

aRts. It has been decided that an optimized subset of aRts, the realtime synthesizer, will be included as the multimedia framework for KDE 2. There has also been a show of interest in aRts from the GNOME camp -- Stefan Westerfeld appears quite committed to meet everyone's concerns.

aRts is now also interoperable with the highly-praised sequencing software Brahms (formerly kooBase). It is now possible to use KDE for professional music to some degree, with future improvements in store. In the long run, the Brahms/aRts combination should become something similar to the CuBase/VST combo. These are exciting times indeed.

Sycoca is the new system configuration cache designed by Waldo Bastian and currently maintained by David Faure. Sycoca is a fast binary cache of mostly static data, generally stored in ASCII config files, such as mimetypes and services. Significantly improved application startup time has already been reported.

Kicker development has picked up pace as well -- it now takes advantage of DCOP and will soon be ready to replace kpanel. Daniel "Mosfet" Duley hacked a very nifty feature that allows any client DCOP application to easily allocate a temporary submenu (and menu items) to kicker. There's no need to restart kicker for the changes to take effect either. Mosfet also made available a screenshot demonstrating docking. Graham TerMarsch implemented a couple of applets and included a small screenshot.

A new toolkit for KDE? Chun Fong wrote in with details on his attempt to port the Fresco toolkit to KDE. Fresco appears to be a nice C++ GUI with thread support and is available under an X11-type license. A new toolkit that supports KDE could possibly be quite beneficial, an existing example is Ktk. Please contact Chun if you are interested in helping with such an effort.

Java. And last, but certainly not least, Lars Knoll's new DOM-based HTML library now includes Richard Moore's integrated support for Java applets -- konqueror will be java-capable! Other KDE applications can also easily embed java applets.

An archive for these reports is available. Une version francaise pourrait eventuellement etre disponible ici.