Date: Thu, 28 Oct 1999 00:05:26 -0400
From: Navindra Umanee <<a
href=”mailto:[email protected]”>[email protected]>

To: [email protected]
Subject: KDE Development News: October 1999 [1/2]

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.