[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Upcoming KDE-1.1 Release
From:       KDE Core Team <core () kde ! org>
Date:       1998-10-12 11:45:25
[Download RAW message or body]


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

[prev in list] [next in list] [prev in thread] [next in thread]