© mathias the dread, Photocase.com

Anwender der Entwicklungsumgebung Kdevelop sitzen derzeit zwischen zwei Stühlen: Während die Entwickler die stabile Version 3.5 fallen gelassen haben, lässt das runderneuerte Kdevelop 4 noch auf sich warten. Rechtfertigen Reife und Features der Beta schon jetzt einen Umstieg?

Nokias hauseigene Qt-Entwicklungsumgebung Qt Creator [1] ist noch jung. Wer bislang Anwendungen für KDE und Qt entwickeln wollte, griff häufig zur IDE Kdevelop [2]. Im Laufe seines Lebens wuchs das Werkzeug jedoch zu einem wahren Funktionsmonster heran, das mit seinen vielen Fenstern und Symbolleisten den Einstieg erschwerte. Auch unter der Haube schien es den Entwicklern zu unübersichtlich zu werden. Kurzerhand zogen sie die Notbremse, warfen den alten Quellcode fast vollständig über Bord und wagten am Reißbrett einen kompletten Neuanfang. Schlanker und übersichtlicher sollte Kdevelop 4 werden.

Hürdenlauf

Das war vor über vier Jahren. Den bislang erzielten Fortschritt demonstriert die recht weit gediehene fünfte Betaversion. Da die Arbeiten an ihrem Vorgänger bereits 2008 eingestellt wurden, erwägen viele Kdevelop-3.x-Nutzer schon jetzt einen Umstieg, unter anderem weil mit der Einbindung von Testwerkzeugen, Cmake und verteilten Versionierungssystemen interessante Features locken. Das Vorhaben entpuppt sich jedoch als recht mühsam. Zunächst erfordert die zum Redaktionsschluss aktuelle Beta 5 (Version 3.9.95) ein möglichst neues KDE 4 als Basis, Version 4.2 ist hierbei das absolute Minimum.

In den Repositories der Distributionen schlummert zudem meist nur ein älteres Kdevelop 4. Da die Entwickler jedoch mit jeder Release zahlreiche Fehler beheben und neue Funktionen einbauen, sollte man möglichst zur letzten Version greifen – was bedeutet, den Quellcode per Hand zu übersetzen. Obendrein stürzte Kdevelop 4 auf einem Testsystem unter Open Suse 11.1 reproduzierbar ab. Das gilt selbst für die etwas ältere Version aus dem Repository.

Die Entwickler haben nicht nur die Benutzeroberfläche generalüberholt, sondern auch gleich den Unterbau in das Projekt Kdevplatform ausgelagert. Hinter dem kryptischen Namen verbirgt sich eine Sammlung aus Bibliotheken, mit deren Hilfe Interessierte sehr einfach IDEs oder IDE-ähnliche Anwendungen erstellen können – hier stand offenbar das Eclipse-Projekt Pate. Die erste Entwicklungsumgebung, die auf Kdevplatform basiert, ist das eigentliche Kdevelop 4. Folglich muss man beide Pakete in zueinander passenden Versionen installieren. Im Moment fällt das nicht weiter schwer, da das Duo einträchtig auf dem KDE-Server wartet [3]. Bei der Installation assistiert der Kasten “Übersetzungshilfe”.

Großes Kino

Das Hauptfenster von Kdevelop 4 gibt sich wesentlich aufgeräumter als in früheren Versionen. Trotzdem tummeln sich rund um den Hauptbereich weiterhin mehrere Register, über die der Anwender zahlreiche Informations- oder Funktionsleisten auf- oder zuklappt. Da ein Entwickler viele von ihnen im laufenden Betrieb benötigt, verlangt Kdevelop nach großen Bildschirmen. Unterhalb einer Auflösung von 1024 mal 786 Pixeln gerät die Arbeit zur Qual.

Der erste Schritt eines Anwendungsentwicklers dürfte geradewegs ins »Project«-Menü führen, wo der kleine Assistent hinter »New From Template« ein neues Projekt erstellt. Fehlt dieser Eintrag, hilft der Kasten “Verschwundene Menüs”. Derzeit kennt der Dialog nur eine C++- sowie einfache KDE- und Qt-Vorlagen. Wer das KDE-SDK installiert hat, kann außerdem ein KDE-4-Ruby-, Py-KDE-4- oder Py-Qt-4-Projekt erstellen. Unterstützung für andere Sprachen lässt sich über Plugins nachrüsten, die teilweise schon im Internet bereitstehen. Von einem vergleichbaren Angebot wie für den Vorgänger Kdevelop 3.5 ist die neue Version jedoch noch weit entfernt.

Abbildung 1: Die automatische Code-Vervollständigung, wie sie auch aus anderen IDEs bekannt ist.

mkdir build
cd build
cmake ../
make
sudo make install

Versionskontrolle

Nach der Auswahl einer Vorlage gibt der Benutzer dem Projekt einen Namen und wählt bei Bedarf ein Versionskontrollsystem, denn Kdevelop 4 arbeitet mit Subversion, Mercurial, CVS und Git zusammen. Abschließend öffnet Kdevelop ein Fenster mit den Build-Einstellungen, in denen man zumindest das »Build Directory« prüfen sollte. Wichtig: Die Entwickler haben das Automake/Configure-Gespann über Bord geworfen und setzen ab sofort durchgehend auf Cmake. Mangels Dokumentation und anderer Hilfen sollten Benutzer dessen Arbeitsweise zumindest ungefähr kennen.

Wenn das Projekt steht, rührt sich auf der Oberfläche scheinbar nichts. Nur wer genau hinschaut, entdeckt am linken Rand das neue Register »Projects«, das alle derzeit geöffneten Projekte verwaltet. Ein Doppelklick auf eine Datei öffnet sie im Texteditor, der sich an den üblichen Standards orientiert: Syntax-Highlighting färbt Schlüsselwörter ein und berücksichtigt dabei auch Qt-Eigenheiten.

Schon während der ersten Tastendrücke öffnet sich ein kleines Fenster, das Vorschläge unterbreitet (Abbildung 1). Diese automatische Code-Vervollständigung kennt neben den Qt- auch die Standard-Bibliotheken und kann mit C++-Templates umgehen.

Unterstützung bei der Eingabe von Methodenparametern ist explizit per [Strg]+ [Leertaste] anzufordern. Von den dann angebotenen Informationen können Nutzer manch anderer IDEs nur träumen. So erfahren sie, welche überladenen Funktionen der Basisklassen nach dem aktuellen Stand aufgerufen würden und welche Objekte und Variablen überhaupt als Argumente in Frage kommen (Abbildung 2). Verschiedene Farben zeigen an, ob zuvor noch eine Typkonvertierung notwendig ist. Auf analoge Weise hilft die Code-Vervollständigung auch beim Verbinden von Signalen und Slots.

Der Editor kann aber noch mehr: Ruft der Anwender in einer »cpp«-Datei die Code-Vervollständigung auf, listet diese nicht nur alle Methoden auf, die noch eine Implementierung benötigen, sondern bietet gleichzeitig an, einen passenden leeren Rumpf zu erstellen (Abbildung 3). Vergisst der Programmierer eine Variable zu deklarieren, ermittelt Kdevelop den passenden Typ und fügt auf Wunsch die notwendige Deklaration ein.

Dank dieser Automatik spart der Benutzer nicht nur Tipparbeit bei kryptischen Templates, er kann Algorithmen auch fast wie in Python direkt herunterschreiben. Fügt er einer Methodensignatur einen weiteren Parameter hinzu, schlägt Kdevelop vor, auch das Pendant in der »cpp«-Datei anzupassen.

Klammern setzt der Editor nur dann automatisch, wenn der Benutzer eine Methode aus den Vorschlägen übernimmt. Immerhin rückt die Software den Quellcode selbstständig ein und ergänzt fehlende »include«-Anweisungen. Codeteile lassen sich schnell mit einem Tastendruck aus- beziehungsweise wieder einkommentieren, der Inhalt von geschweiften Klammern einfach wegklappen. Per Mausklick auf den linken Fensterrand verteilt der Benutzer Haltepunkte für den Debugger und versieht wichtige Zeilen mit einem Lesezeichen.

Abbildung 2: Komfortabel: Da der erste Parameter der Methode vom Typ »string« ist, bietet die automatische Code-Vervollständigung alle sichtbaren String-Variablen an – hier also »farbe1« und »farbe2«.

Abbildung 3: Da die Methode »setzeFarbe()« noch keine Implementierung besitzt, schlägt die automatische Code-Vervollständigung vor, eine leere anzulegen.

Mittelklasse

Der populäre Klassenbrowser aus der Vorversion blieb glücklicherweise erhalten (Abbildung 4). Er listet sämtliche Klassen sowie ihre Attribute und Methoden auf. Ein Diagramm der Klassenbeziehungen fehlt aber weiterhin.

Apropos grafische Darstellung: Von der versprochenen Integration des Qt Designer war zumindest in der getesteten Betaversion nichts zu sehen. Doppelklickt der Benutzer eine ».ui«-Datei, erscheint zwar eine Vorschau des entsprechenden Fensters, manipulieren darf er die Elemente jedoch nicht.

Beim Anlegen einer neuen Klasse hilft ein rudimentärer Assistent. Er setzt voraus, dass der Programmierer die Namen der Basisklassen kennt. Anschließend darf dieser immerhin anklicken, welche virtuellen Funktionen die neue Klasse überschreiben muss. Dafür kann Kdevelop 4 die Klassen und Variablen im gesamten Projekt umbenennen. Dazu markiert der Anwender einfach den betroffenen Namen und wählt im Kontextmenü »Rename«. Ein neues Fenster zeigt alle Vorkommen des Bezeichners im Projekt und bittet um die Eingabe des neuen Namens. Diese Hilfe erleichtert besonders das Refactoring, gehört aber mittlerweile zum Standardrepertoire einer guten IDE.

export KDEDIRS=$KDEDIRS:/usr/local

kbuildsycoca4

Tour durch den Quelltext

Ein Mausklick auf einen Klassennamen, während rechts oben das Symbol der grünen Glühbirne eingedrückt ist, öffnet die entsprechende Headerdatei. Mit diesem Source-Browse-Modus “surft” der Programmierer in einer unglaublichen Geschwindigkeit durch eigene und fremde Quelltexte. Nach dem gleichen Prinzip arbeitet der Codebrowser am unteren Rand. Er liefert vielfältige Informationen über den gerade markierten Bezeichner und somit ähnliche Daten wie Doxygen. Per »Show uses« sucht das Fenster zudem alle Stellen heraus, an denen dieses Objekt zum Einsatz kommt – nicht nur beim Refactoring äußerst praktisch.

Über das »Quick Open«-Eingabefeld am oberen Rand navigiert der Benutzer schnell zu einem gesuchten Element. Noch während er ein Suchwort eintippt, erscheint eine Liste mit allen in Frage kommenden Fundstellen. Hebt er eine von ihnen per Maus oder Pfeiltasten hervor, erscheinen nicht nur die zugehörige Datei, sondern auch weitere Informationen, zum Beispiel der Rückgabewert bei Methoden.

Für nahezu jede Aktion kennt Kdevelop ein passendes Tastenkürzel, mit ihnen lässt sich blitzschnell im Code navigieren. [Strg]+[+] springt beispielsweise direkt zur Deklaration des gerade selektierten Objekts. Es dürfte jedoch einige Zeit vergehen, bis der Anwender bei dem gebotenen Funktionsumfang alle Kürzel auswendig kennt. Wer große Projekte zu stemmen hat, kämpft irgendwann mit vielen geöffneten Registern. Kdevelop versucht diese Flut mittels so genannter Working Sets einzudämmen. Sie gruppieren zusammengehörige geöffnete Quellcode-Dateien. Diese Gruppen lassen sich dann mit nur einem Mausklick ein- und ausblenden. Bildlich kann man sich ein Working Set wie eine Schublade vorstellen, in der alle gerade geöffneten Dateien landen.

Abbildung 4: Der altbekannte Klassenbrowser ist wieder mit von der Partie.

Bauarbeiter

Um das fertige Projekt zu übersetzen, existieren zwei Wege: Zum einen kann der Entwickler »Project | Build« aufrufen, vorausgesetzt er hat den Ordner im »Projects«-Fenster markiert. Das übersetzte Ergebnis lässt sich aus Kdevelop heraus sogar installieren (»Install«). Damit dies allerdings reibungslos klappt, muss er sich zuvor durch die kryptischen Cmake-Einstellungen hangeln (Kontextmenü im »Project«-Reiter, dann »Open Configuration …«). Darüber hinaus ist dieses Angebot auch etwas gefährlich, insbesondere wer Systemsoftware entwickelt, sollte tunlichst ein spezielles Installationsverzeichnis wählen.

Alternativ zu dieser schnellen Übersetzungsmethode lassen sich einzelne Projekt beziehungsweise einzelne Dateien dem so genannten Buildset hinzufügen (per Klick auf das grüne Pluszeichen auf dem »Projects«-Register). Alle in dieser Warteschlange eingereihten Elemente übersetzt Kdevelop in einem Rutsch. Das ist besonders dann nützlich, wenn der Benutzer mehrere Bibliotheken und die darauf aufbauende Anwendung in verschiedenen Projekten verwaltet.

Um das erstellte Programm testen zu können, muss der Entwickler zunächst eine Ausführungsumgebung einrichten. Das gesamte Vorgehen und der dahinterstehende Schirm ist für Einsteiger alles andere als intuitiv und beginnt mit dem Menüpunkt »Run | Configure Launches«. Die Fummelarbeit hat allerdings ihren Lohn: Für ein Projekt lassen sich mehrere Laufzeitumgebungen erstellen, von denen beispielsweise jede die übersetzte Anwendung mit anderen Kommandozeilen-Parametern füttert. In Kdevelop 4 reichen dann wenige Mausklicks, um eine der Varianten aufzurufen.

Kammerjäger

Einen Lauf unter den Augen des Debuggers wirft »Run | Debug Launch« an – vorausgesetzt die Build-Einstellungen stimmen. Kdevelop wechselt dabei die Ansicht und tauscht die bisherigen Werkzeuge gegen Pendants für das Debugging aus. Dummerweise ähneln sich Debug- und Code-Ansicht, zumal für die Breakpoints auch noch die entsprechenden Quellcode-Dateien auf dem Schirm erscheinen. Gerade Einsteiger dürften hier hin und wieder leise fluchen, weil sie nach einem automatischen Ansichtswechsel eine bestimmte Funktion vermissen. Hier wäre eine striktere Trennung wie im Qt Creator wünschenswert.

Steile Lernkurve

Kdevelop 4 ist auch in der aktuellen Version voll auf die C++-Programmierung von KDE und Qt-Programmen ausgerichtet. Im Gegensatz zum direkten Konkurrenten Qt Creator erweist sich die IDE weiterhin als Funktionsmonster, das mit einer wenig intuitiven Benutzeroberfläche aufwartet – obwohl Usability eigentlich das erklärte Ziel der Neuentwicklung war. Konzepte wie die Working Sets sind zwar interessant, sorgen aber für eine relativ steile Lernkurve und verhindern so einen schnellen Einstieg.

Erschwerend kommt hinzu, dass derzeit weder eine Dokumentation noch eine Onlinehilfe existieren. Die Anleitungen für das alte Kdevelop 3.5 lassen sich nur selten übertragen. Einige Anhaltspunkte für Wechsler gibt der Kasten “Differenzen für Umsteiger”

Beim Debuggen und Testen kann Kdevelop gegenüber Qt Creator hingegen punkten – wenn der Anwender willens ist, sich mit der komplexeren Konfiguration auseinanderzusetzen. Insbesondere die Integration des Profilers Valgrind ist schon fast ein Alleinstellungsmerkmal. Die extrem intelligente Code-Vervollständigung hilft Fehler vermeiden und nimmt dem Programmierer lästige Tipparbeit ab.

Der IDE merkt man das frühe Entwicklungsstadium aber deutlich an. In den Tests für diesen Artikel stürzte sie immer wieder ab. Wer schon jetzt Kdevelop 4 ausprobieren möchte, sollte seine Arbeit häufig zwischenspeichern. (mhu)