Dear developers, since KDE 1.0 was released, much has happened. Bugs were fixed and several features were added. Now the time has come to free the paths for the next-generation KDE. The new KDE will be a component system, using Corba as one of its base technologies. KOffice, as well as the new filemanager (kfm III), are the most prominent examples of Corba usage in the upcoming new KDE. Adding a CORBA-fied base component (kfm III) will have major impact on the code base. Much work has to be done to straighten out possible problems. What does this mean for developers? 1. About KDE 1.1 ---------------- KDE 1.1 will be released before starting the big effort in turning KDE into "KDE Next-Generation". So if you have applications in the CVS and have pending changes, apply them as soon as possible. For releasing KDE, a standard release schedule will be used, starting in 14 days (Oct 26 1998): 2. About KDE, the next-generation (KDE NG) ------------------------------------------ KDE NG will be much more component centered than the current one - Corba being the base object technology. The MICO ORB is already used for KOffice and kfm III, as it is the most complete free CORBA implementation. MICO (http://www.vsb.informatik.uni-frankfurt.de/~mico) can be considered the standard ORB for KDE. There are some unneccasary doubts in the usabilty of CORBA. Here are some answers to common questions. Q: CORBA is sometimes said to be huge and slow, so why should KDE use it? A: Components are very useful - the Adressbook is a standard example. Other useful components are mail services (compose and send mail), spell checkers, file services (retrieve file from filesystem, ftp, http). A: CORBA is only half as big as many might think. On a developer congress in Cologne/Germany the CORBA-using KOffice ran on a P-120 laptop, showing it's output on a remote X display. And it was impressingly fast. Q: But my computer even failed to compile MICO, I have not enough RAM. A: egcs1.1 needs much less memory for compilation, for example 20MB less on a Sun. A: A precompiled MICO could be offered. 3. Needed tools for KDE NG -------------------------- MICO uses a lot of features that ANSI C++ offers (Namespaces, Templates). You will need a compiler that complies as good as possible to the ANSI C++ standard. For the time being, this means egcs. egcs has the additional advantage of supporting STL. STL alone is a good reason for updating. It is extremely useful and saves so much programming time, that you really should consider upgrading to egcs. Many distributions like DLD and RH already ship egcs, others will add it to their next distribution. 4. Changes from KDE1.0 to KDE1.1 -------------------------------- - KDE libraries now carry the major number 2, for example libkdeui.so.2.0.0 - KDE libs with major 2 are NOT binary compatible to KDE libs with major 1 Additionaly, one neccesary interface change had to be introduced into KDE1.1, regarding the KKeyConf class (header file kkeyconf.h) Since KKeyConfig lacked some important features, Mark Donohoe, Nicolas Hadacek and Matthias Ettrich developed it further to KAccel which is now in libkdecore. The main advantages are easier usage, and the internationalization of the function descriptions in the keybinding editor. Unfortunatly both concepts KKeyConfig and KAccel are not completely source compatible, but the porting is pretty easy. See http://www.kde.org/bulletin/kdelibs-changes-12Oct1998.html for migration notes. The KDE Core Team (In alphabetic order): Roberto Alsina Kalle Dalheimer Mark Donohoe Christian Esken Matthias Ettrich Steffen Hansen Matthias Hoelzer Martin Jones Sirtaj Singh Kang Martin Konold Stephan Kulow Richard Moore Sven Radej Reginald Stadlbauer Stefan Taferner Uwe Thiem Mario Weilguni Torben Weis Robert David Williams Bernd Wuebben Markus Wuebben