Wenn der Schwerpunkt von KDE 2.2 auf der Weiter- und Neuentwicklung von Applikationen liegt, steht eines der größten KDE-Core-Projekte nicht hintan: Die integrierte Entwicklungsumgebung KDevelop glänzt in der neuen Version vor allem mit einer modernisierten Benutzeroberfläche.

Seit KDE 2.1 gehört KDevelop als die C- und C++-Entwicklungsoberfläche für KDE- und Qt-Programmierung zum Paketumfang der Desktop-Umgebung. Damit war dem KDevelop-Team von Anfang an klar, dass auch KDE 2.2 in Bezug auf KDevelop Neues liefern muss. User-Wünsche gab es einige, doch da der Zeitrahmen bis zur Beta mit zirka vier Monaten recht eng war, galt es, die Neuerungen gut zu planen.

Versionen, Features und Branches

An bereits programmiertem Rohmaterial war einiges vorhanden; schließlich gibt’s schon seit mehr als einem Jahr ein experimentierfreudiges Nebenprojekt, das an einem KDevelop-Rewrite bastelt, um in erster Linie die architektonischen Beschränkungen der Vorgängerversionen zu überwinden. Die Ernsthaftigkeit der Absicht unterstreichen die Entwickler schon damit, dass sie diese Sourcen – unter dem Codenamen Gideon laufend – auf den Haupt-Branch des CVS verlegt haben. Die Arbeit wird aber noch einige Zeit in Anspruch nehmen.

Deshalb entschied sich das KDevelop-Team, an der alten soliden Codebasis der 1.x-Reihe auf dem bereits existierenden CVS-Branch »KDEVELOP_1_4« parallel weiterzuarbeiten und mit einer komplett überarbeiteten Benutzeroberfläche den Programmierkomfort in der Entwicklungsumgebung entscheidend zu verbessern. Das zweite Ziel, die beim User allseits beliebte Code-Komplettierung zu implementieren, musste leider mangels geeigneter Experten wieder fallen gelassen werden.

Für die neue Oberfläche standen die Sterne aber günstig und im Laufe der Zeit kamen noch weitere nützliche Neuerungen dazu, so dass der Schritt zur neuen Major-Version 2.0 durchaus seine Berechtigung hat und damit KDE 2.2 in seiner Absicht, eine Version mit neuen Features zu sein, unterstützt.

Die Veränderungen

Über den Entwicklungszeitraum gesellte sich zur unermüdlichen Öffentlichkeitsarbeit von Ralf Nolden und der Arbeit des Autors am GUI-Redesign wertvolle Hilfe durch John Birch, Christian Chouder, Roland Krause und Harald Fernengel. Dieser internationalen Kerngruppe von Freizeitprogrammierern arbeiteten weitere KDeveloper zu, so dass die neue Release mit einer stattlichen Anzahl von Neuerungen aufwarten kann (siehe Kasten “Neu in KDevelop 2.0”).

Programmtechnisch gesehen lagerte die Applikation große Teile ihres Binaries in eine Sammlung dynamisch gelinkter Bibliotheken aus. Zudem stellten wir intern einige Programmstrukturen grundlegend um, um das Programmieren an dem nun immerhin 75000 Quellcodezeilen großen Projekt zu erleichtern. Dazu kamen wie immer viele Bugfixes bezüglich der Vorgängerversionen.

Neues an der Oberfläche

Wer programmiert, merkt schnell, dass es die Arbeit sehr erleichtert, wenn verschiedene Sichten auf das Programm – auf Klassen und Funktionen, Dateien, Projekt oder Dokumentation – zur Verfügung stehen. Sie sind für den C++-Programmierer ebenso selbstverständlich und nicht mehr wegzudenken wie unterschiedliche Fenster für die Ausgaben von Compiler, Debugger, Programm oder der Entwicklungsumgebung selbst. KDevelop unterstützt all dies bereits in bisherigen Versionen schon recht gut.

Die wichtigste Forderung an eine Entwicklungsumgebung ist aber nach wie vor der Komfort, den sie bei der Arbeit am Quellcode bietet. Dazu gehört neben einem das Programmieren unterstützenden Editor ein möglichst geringer Aufwand beim Suchen, Vergleichen und Wechseln der Dateien. Allerdings hat jeder Benutzer in dieser Beziehung andere Vorstellungen von einer guten IDE, oft bedingt durch die im Umgang mit verschiedenen Systemen erworbenen Gewohnheiten. Die ideale Entwicklungsumgebung ist also voll konfigurierbar.

Bis Version 1.4 war das KDevelop-Oberflächenkonzept in dieser Hinsicht noch recht einfach gestrickt. Eine der drei tabulatorartig angeordneten Header-, Source- und Dokumentationsbrowser-Ansichten kann angewählt und mit einer passenden Datei geladen werden, doch ist damit immer nur eine Sicht auf den Quellcode zur gleichen Zeit möglich.

Mit KDevelop 2.0 sollte sich dieses Konzept mit einfachen Mitteln wesentlich verbessern. Intern übernimmt eine Manager-C++-Klasse die Implementierung des Dokument-View-Modells; die Visualisierung der Oberfläche bleibt aber komplett der externen GUI-Bibliothek »QextMDI« überlassen, die damit eine Schlüsselfunktion einnimmt.

Sie stellt zur Zeit vier Benutzeroberflächen-Modi zur Verfügung, von denen die drei MDI-Modi Childframe, Tabpage und Toplevel für KDevelops neue Oberfläche sehr gut geeignet sind. Kommen in Zukunft weitere hinzu, profitiert das Programm automatisch davon.

Zum Vergleich: Die alte Benutzeroberfläche von KDevelop 1.4.

Es darf gewählt werden

Über »Optionen | KDevelop Einrichtung | Benutzerschnittstelle« kann der KDevelop-Anwender jederzeit in einen der drei Modi umschalten. Der Childframe-Modus stellt die typische, von Windows gewohnte MDI-Oberfläche ein, ein Muss für jeden Fan der MS-Visual-C++-Oberfläche. Innerhalb eines Programmrahmenfensters erscheint eine beliebige Anzahl Editor- und Browser-Ansichtsfenster als Toplevel-Fenster. KDevelop-fremde Fenster werden damit komplett ausgeblendet, so dass eine Art Programmierdesktop entsteht.

Immer auf größtmöglichen Platz für den Editor bedacht arbeitet der Programmierer darin in der Regel mit maximierten Fenstern; verschiedene Fenster-Anordnungsfunktionen unterstützen aber auch die gleichzeitige Sicht auf mehrere Quelldateien. Für das Vergleichen von Dateien ist dieser Modus daher sehr geeignet.

Zusätzlich zu den von Windows-MDI-Programmen bekannten Eigenschaften erlaubt der Childframe-Modus aber auch das schnelle Umschalten der Views per KDevelop-eigener Taskleiste und das Abdocken von Ansichtsfenstern auf den KDE-Desktop. Letzteres gibt dem Anwender die Möglichkeit, seine aus dem KDevelop-Hauptfenster losgelösten Editor- und Browserfenster auf allen virtuellen Desktops zu verteilen.

Ganz weit oben auf der Beliebtheitsskala liegt der Tabpage-Modus. Prinzipiell ähnelt er stark den Oberflächen von IDEs wie KDEStudio oder Borland Builder. Auch KDevelop 1.4 funktionierte nach diesem Prinzip, nur sind jetzt beliebig viele Sichten auf Quellcode oder auch Dokumentation gleichzeitig ladbar. Wie auch im Childframe-Modus gibt es die Dreiteilung in gedockte Baum- und Ausgabeansichten und den Bereich für die Dateiansichten. Der Unterschied ist, dass Letzterer alle Views nach dem Karteireiterprinzip anordnet. Damit werden alle Dateien sehr übersichtlich dargestellt. Die Reiter wirken platzsparend, zeigen ähnlich wie die Taskleiste für die Ansichtsfenster die benachbart angeordneten Dateien und erlauben schnelles Umschalten per Mausklick.

Tastaturfans können sich in allen drei Modi per [Alt]+[Bild-ab] beziehungsweise [Alt]+[Bild-auf] durch die Liste der geöffneten Quellen oder Dokumentationsbrowser-Ansichten bewegen. Ein großer Nachteil des Tabpage-Modus ist aber, dass immer nur eine Datei gleichzeitig angezeigt wird. Zum Vergleichen mehrerer Files muss man also den GUI-Modus wechseln.

Die für Unix-User wohl vertrauteste Oberfläche bietet der Toplevel-Modus, der sich stark am Design von Programmen wie Gimp oder Yast2 anlehnt. Zentraler Punkt ist das Steuerungsfenster, das Menü, Werkzeugleisten und Statusleiste enthält. Einen programmeigenen Bereich für die Werkzeug- und Arbeitsansichtsfenster gibt es hier nicht; dafür wird traditionell der Desktop genutzt.

KDevelop dockt standardmäßig Baumansichten sowie die Ausgabeansichten jeweils in einem Fenster zusammen, das auf dem Desktop liegt. Wie in den anderen Modi ist es auch möglich, die Werkzeugansichten noch weiter ab- oder umzudocken. Geöffnete Sichten auf eine Datei werden kaskadiert dargestellt.

Im Toplevel-Modus ist es also sehr gut möglich, viele Views gleichzeitig sichtbar zu machen. Der größte Vorteil ist aber, dass parallel geöffnete fremde Programme nicht von einem KDevelop-Hauptfenster überdeckt werden. Der Modus eignet sich also sehr gut, um parallel beispielsweise mit KIconEdit, Qt Designer oder KDbg zu arbeiten. Nachteilig wirkt er sich aus, wenn der Benutzer ausschließlich mit KDevelop arbeitet und programmfremde Fenster eher stören. Unix bietet dafür eine Lösung: die Nutzung unterschiedlicher virtueller Arbeitsflächen.

Will man jedoch auf Fensteranordnungsfunktionen zurückgreifen, funktionieren die der MDI-Steuerung von KDevelop nur im Childframe-Modus. Für den Toplevel-Modus ist hierfür der jeweilige Fenstermanager verantwortlich. Jedoch konnte ein Bug bis zur Release 2.0 nicht behoben werden, so dass Fenster im Fenstermanager-Modus Focus-follows-mouse automatisch aktiviert werden, was der Anwender wohl eher als störend empfindet. Sehr zur Freude aller Tastaturfreaks funktionieren Hotkeys und Accelerators über den Views aber ohne Probleme.

Alles in allem ist in Sachen Konfigurierbarkeit der Oberfläche für wohl jeden etwas Passendes dabei. Das KDevelop-Team legte vor allem Wert darauf, den Gewohnheiten sowohl eingefleischter Unixer als auch der von Windows-Umsteigern besser entgegenzukommen.

Ein neuer Modus für die KDevelop-Benutzerschnittstelle.

KDevelop 2.0 im Childframe-Modus.

Im Tabpage-Modus wird immer nur eine Datei angezeigt.

Neustart ohne Verluste

Mit der neuen Version verwaltet KDevelop nun auch Projekt-Sitzungen. Die Anwendung merkt sich dabei nicht nur das zuletzt geöffnete Projekt, sondern öffnet nach einem Programmneustart alle früheren Quellcode- und Browser-Fenster, restauriert deren Geometrien, scrollt und setzt sogar den Cursor in Quelldateien wieder an die alte Position. Alle projektspezifischen Session-Informationen werden getrennt von der Projektdatei in einer ».kdevses«-Datei gespeichert. Damit ist es nun möglich, die ».kdevprj«-Projektdatei ins CVS zu stellen, ohne dass es in Team-Projekten zu CVS-Konflikten kommt.

So präsentiert sich KDevelop im Toplevel-Modus.

KDE-Programmierung erleichtert

Für alle, die sich von KDevelop Unterstützung für die KDE-Programmierung versprechen, sind in der Version 2.0 neue Projekt-Templates dabei. Über »Projekt | Neu | KDE« bietet der Projektassistent jetzt noch mehr Gerüste für verschiedene Plug-ins und Erweiterungen zu bekannten KDE-Applikationen. Damit wird dem angehenden KDE-Programmierer der oftmals schwierig erscheinende Einstieg in komplexere C++-Projekte wesentlich erleichtert.

Keine Navigationsprobleme

Eine eingebaute »ctags«-basierte Datenbank unterstützt ab KDevelop 2.0 das komfortablere Navigieren im Quellcode. Ein Klick mit der rechten Maustaste an der Aufrufstelle einer Methode oder Klasse im Quelltext lässt ein Popup-Menü erscheinen, das den Sprung zur jeweiligen Deklaration und Definition erlaubt. Weiterhin gibt es in diesem Menü auch einen Eintrag zum Wechseln zwischen Header- und Sourcedatei.

Voraussetzung für das Funktionieren des Features ist, dass der Benutzer das »ctags«-Datenbank-Feature unter »Projekt | Einstellungen | Dokumentation« angeschaltet und das Anlegen der Datenbank beim Erzeugen eines neuen Projekts bestätigt hat.

Bereit mit neun Klicks

Eine auffällige Neuerung in Version 2.0 begrüßt den Anwender gleich nach der Installation. Es handelt sich um das völlig neu geschriebene KDevelop-Setup, das im modernen Look & Feel eines Assistenten durch die verschiedenen Seiten leitet. Nach der Übersichtsseite kommt der User über »Weiter« zur Auswahl des Syntax-Highlighting-Styles; KDevelop steuert ab dieser Version einen dritten, MSVC-ähnlichen Stil bei.

Danach erfragt der Assistent den gewünschten Oberflächenmodus und prüft das Vorhandensein der Basistools, zum Beispiel »kdoc« und »automake«. Alle gewählten Einstellungen werden erst am Ende des Setups in KDevelop übernommen; der Benutzer kann jederzeit zu vorangegangenen Seiten zurückwechseln oder abbrechen ohne zu speichern.

Weiter geht es mit der automatischen Erkennung von Qt- und KDE-Dokumentationen. Gibt es dabei Schwierigkeiten, kann man per Hand nachhelfen. Seite »7 of 9« generiert aus den anzugebenden Quellcodes zum Paket »kdelibs« eine komplette Dokumentation in HTML. Zuletzt erzeugt der Assistent wahlweise mit Hilfe von »htdig« oder »glimpse« eine Indexdatenbank der Dokumentation, um die Suche zu optimieren.

Nützliches Sammelsurium

Auch verschiedene kleinere Änderungen bringen neuen Schwung in die Entwicklungsumgebung. Die Menüoption »Klänge | Systemnachrichten | KDevelop« im KDE-Kontrollzentrum beispielsweise ermöglicht selbst definierte IDE-Ereignisse. Oder wie wäre es mit der Hervorhebung von korrespondierenden Klammern im Quelltext? Kein Problem, wenn »Optionen | Editor | Klammerung hervorheben« gesetzt ist. Auch das Laden von ».po«- und ».xpm«-Dateien als Textfiles ist kein Problem mehr.

Überhaupt sind beim Programmieren Rückgriffe auf externe Programme viel seltener erforderlich; eine eingebaute Konsole erlaubt den Zugriff auf die Kommandozeile und »Hilfe | Manpage anzeigen für« zeigt die entsprechenden Hilfen in farbenfrohem HTML-Layout an.

Passend zur neuen GUI werden Warnungen und Fehler in der Compiler-Ausgabe rot dargestellt. Auch Bugs aus Version 1.4, zum Beispiel das lästige Abdocken der Ausgabefenster oder das spontane Verbreitern des Hauptfensters beim Debuggen, gehören der Vergangenheit an. Stattdessen kann der KDevelop-Benutzer sich freuen, dass das Drucken und Details wie der Tip des Tages an KDE-Standards angepasst wurden.

Das neue KDevelop-Setup erscheint im Gewand eines Assistenten.

Entwicklung nonstop

Version 2.0 ist ein Vorgeschmack auf den für nächstes Jahr geplanten großen Sprung auf die Serie der KDevelop-3.x-Versionen. Eine komplett neu entworfene innere Programmarchitektur erlaubt dann das modulare Programmieren in KParts-Technologie.

Die neue Versionslinie wird in vielerlei Hinsicht wesentlich universeller ausgerichtet sein. Dazu zählen beispielsweise die Integration neuer Programmiersprachen, Compiler und Editoren. Schon jetzt gibt es auf dem Experimentier-Branch laufende Unterprojekte, mit denen die IDE auch für die PHP-, Java- sowie Fortran-Programmierung einsetzbar wird.

Ebenfalls in Entwicklung befinden sich KParts für die Unterstützung von Projekten, die auf »tmake« respektive »qmake« beruhen, für die Code-Vervollständigung oder zur Integration von NEdit.

Programmierer, die an der KDevelop-Entwicklung mitwirken wollen, sind herzlich willkommen. Für laufende Teilprojekte sucht das Team dringend Mitstreiter, denn viele Wünsche, etwa die Integration von Emacs, liegen aus Personalmangel auf Eis. Wer Zeit und Lust hat, sollte sich über die Mailingliste [kdevelop@kdevelop.org] melden. Der Zeitpunkt ist günstig – die Signale für KDevelop stehen auf Grün. (pju)