Aus Linux-Magazin 01/2002

Qt-Version 3.0

Wie nennt sich eine plattformübergreifende Widget-Bibliothek, die Datenbankklassen, GUI-Builder, Code-Editor, Übersetzungswerkzeug, Build-Tool und mehr enthält? "Multi-platform C++ Graphical User Interface Development Framework" oder kurz Qt 3.0.

Wenn Masse ein Kriterium ist, kann Qt-Hersteller Trolltech sich beruhigt zurücklehnen: Mit reichlich 16 MByte gepacktem Sourcecode für X11 schlägt die Version 3.0 den Vorgänger Qt 2.3 (rund 8.5 MByte in der aktuellen Maintainance-Release 2.3.2) um Längen. Der Mehrwert verteilt sich auf neue Klassen (darunter ein SQL-Datenbank-Modul), zusätzliche und erweiterte Applikationen – und nicht zuletzt auf ein weiteres unterstütztes Betriebssystem: MacOS X.

Nicht in diese Release geschafft hat es hingegen das bis zur (vorletzten) Beta 5 noch enthaltene Komponentenmodell QCom. Schlecht dokumentiert und auch sonst auffallend von der sonst meist einleuchtenden Qt-API abweichend, konnte es die Teilnehmer am öffentlichen Betatest nicht begeistern, so dass die Norweger letztlich die Notbremse zogen. Damit die auf QCom basierende neue Plug-in-Architektur dennoch funktioniert, sind Teile der Komponenten-API weiterhin im Code enthalten.

Plug in!

Eigene Styles, Datenbanktreiber, Text-Codecs oder Grafikformate lassen sich damit als Plug-ins in Qt integrieren. So findet man die JPG-, PNG- und MNG-Unterstützung (sofern Qt entsprechend kompiliert wurde) als Bibliotheken unterhalb von »$QTDIR/plugins/imageformats« wieder, ebenso ausgelagert wurden beispielsweise die Qt-eigenen Styles (»$QTDIR/plugins/styles«).

Plug-ins leiten sich von Basisklassen wie etwa »QStylePlugin«, »QSqlDriverPlugin«, »QTextCodecPlugin« oder »QImageFormatPlugin« ab. Das Makro »Q_EXPORT_PLUGIN( neuePluginKlasse )« sorgt dafür, dass automatisch ein entsprechendes Plug-in-Objekt erzeugt wird.

»QSqlDriver«- und »QStylePlugins« können Objekte verschiedener Klassen kreieren. Dazu implementiert man die virtuelle Funktion »create ( const QString& )« und gibt je nach Wert des Argumentstrings ein passendes Objekt zurück. Bei den Bildformat-Plug-ins installiert man dagegen einen I/O-Handler (»installIOHandler( const QString& )«). Die zweite zu implementierende virtuelle Funktion, »keys()«, gibt als »QStringList« eine Liste all jener Klassen zurück, von denen das Plug-in Objekte erzeugen kann. Listing 1 zeigt ein Beispiel für ein Style-Plug-in. Für Text-Codec-Plug-ins sieht die API etwas komplexer aus.

GUI-Builder plus

Auch das RAD-Tool Qt Designer lässt sich durch Widget-Plug-ins (»QWidgetPlugin«) um eigene Widgets erweitern. Doch das ist nicht die einzige Gelegenheit, bei der gestöpselt wird: Anstelle des einfachen GUI-Builders, der das Erstellen grafischer Benutzerschnittstellen unterstützt, findet sich jetzt ein Programm, das – dank eigener Plug-ins – auf dem Weg zur IDE ist.

Ein C++-Editor-Plug-in mit Syntaxhighlighting erlaubt es nunmehr, auf das Subclassing der per GUI-Builder erzeugten Widget-Klassen zu verzichten, wenn es ans Implementieren der Funktionalität geht. So bekommt jede User-Interface-Datei (».ui«), die die XML-Beschreibung eines Widgets enthält, ein ».ui.h«-File zugeordnet, das für die Slot-Implementierungen dieser Klasse gedacht ist. Hier zeigt der Code-Editor seine Stärke: Fügt man die Definition eines neuen Slots ins ».ui.h«-Fenster ein oder ändert hier den Namen eines bereits definierten Slots, hat das unmittelbare Auswirkung auf den »Source«-Reiter des »Object Explorers« (und umgekehrt).

Da der Designer nunmehr komplette Projekte verwaltet und »tmake«- beziehungsweise »qmake«-Projektdateien einliest und selbst erstellt, besteht die Möglichkeit, beliebige Code-Dateien im Designer zu bearbeiten: Unter »File | New« stehen nicht mehr nur Widget-Templates, sondern auch Projekt- und Quelldateien zur Verfügung (Abbildung 1).

Allerdings kann durchaus auf Widrigkeiten stoßen, wer versucht eine alte Projektdatei oder ein neues Projekt auf diesem Weg um die typische Qt-»main()«-Datei zu erweitern: Bevor nicht mindestens ein Widget im Designer erzeugt wurde, steht man vor einem nichts sagenden Dialog (Abbildung 2), dessen »Help«-Button vor sich hin schweigt.

Derlei Probleme mit der Online-Hilfe sind leider keine Seltenheit. Ob die (im »Help«-Hauptmenü unter der eher unpassenden Bezeichnung »Contents« zu findende) interaktive Hilfe im »Property Editor« vollständig versagt und den Hilfesuchenden mit »There is no documentation available for this property« bescheidet oder ob der Hilfe-Knopf verschiedener Dialoge zwar brav den neu hinzugekommenen Qt Assistant aufruft, der jedoch keinen passenden Hilfetext anzuzeigen vermag – als Trost bleibt nur, dass das Designer-Handbuch anfängt, diesen Namen tatsächlich zu verdienen.

Dafür bietet der neue Designer endlich auch Unterstützung für Konzepte wie Actions oder das Layouten mit Splittern, die in Qt 2.3.x denen vorbehalten waren, die ihre GUIs per Hand erstellten. Mit einem (in der Standardkonfiguration der Free Edition nicht vorkompilierten) Plug-in importiert das Programm übrigens auch XML-Beschreibungen von Widgets, die mit dem Gtk-RAD-Tool Glade [1] erstellt wurden – das Ergebnis ist jedoch noch nicht zufrieden stellend (Abbildung 3).

Abbildung 1: Nicht mehr nur Widget-Templates.

Abbildung 1: Nicht mehr nur Widget-Templates.

Abbildung 2: Wer noch kein Widget im Designer erzeugt hat, bleibt ratlos.

Abbildung 2: Wer noch kein Widget im Designer erzeugt hat, bleibt ratlos.

Abbildung 3: Noch lückenhaft: Glade-Import im Designer.

Abbildung 3: Noch lückenhaft: Glade-Import im Designer.

Projektmacher

Projektdateien, wie sie der 3.0er Designer erstellt, lassen sich mit dem bisher zur automatischen Generierung von Makefiles verwendeten Perl-Skript »tmake« nicht mehr interpretieren. Doch da der in C++ verfasste Nachfolger »qmake« (anders als »tmake«) Bestandteil der Qt-Distribution ist, spricht nichts gegen einen Umstieg, zumal die Syntax der Projektdateien für »qmake« lediglich erweitert wurde.

Neu ist etwa die Möglichkeit, plattformspezifische Dateien in ».pro«-Files aufzunehmen

unix {
  SOURCES += app_unix.cpp
}

oder Fehlermeldungen zu geben, wenn benötigte Dateien nicht vorhanden sind:

!exists( main.cpp ) {
  error( "main.cpp fehlt!" )
}

Außer »exists()« und »error()« kennt »qmake« weitere einfache, verschachtelbare Funktionen, etwa »systems( Shell-Kommando)«, um Shell-Kommandos aus-zuführen, oder »include( .pro-File)«, um weitere Projektdateien einzulesen.

Auch die Liste der in einer Projektdatei möglichen Variablen hat sich beträchtlich erweitert: So kann die Variable »FORMS« vom Designer erzeugte ».ui«-Dateien enthalten. »qmake« sorgt dann selbstständig für die Generierung der entsprechenden C++-Source-Dateien mit dem User-Interface-Compiler »uic«.

Übersetzer

Sofern das Projekt-File die Namen von Dateien enthält, die für die Aufnahme lokalisierter Meldungen, für Menüeinträge und Ähnliches gedacht sind, etwa

TRANSLATIONS = app_de.ts app_fr.ts

extrahiert der Befehl »lupdate .pro-Datei« alle im Code von »QObject::tr()« umschlossenen Zeichenketten in die entsprechenden ».ts«-XML-Files. Mit dem Qt Linguist (Abbildung 4), der in Qt 3.0 erstmals offiziell auftaucht, werden diese kontrolliert in die Zielsprache übertragen.

Bei einer Release-Anweisung wird aus der ».ts«-Datei mittels »lrelease« ein binäres ».qm«-File, das sich wiederum von einem »QTranslator« laden lässt (siehe Listing 2).

Abbildung 4: Übersetzungshelfer für internationalisierte Qt-Programme.

Abbildung 4: Übersetzungshelfer für internationalisierte Qt-Programme.

Listing 1: SGI-Style als Qt-Plug-in

#include <qstyleplugin.h>
#include <qsgistyle.h>

class SGIStyle : public QStylePlugin
{
public:
    SGIStyle();

    QStringList keys() const;
    QStyle *create( const QString& );
};

SGIStyle::SGIStyle()
: QStylePlugin()
{
}

QStringList SGIStyle::keys() const
{
    QStringList list;
    list << "SGI";
    return list;
}

QStyle* SGIStyle::create( const QString& s )
{
    if ( s.lower() == "sgi" )
        return new QSGIStyle();

    return 0;
}

Q_EXPORT_PLUGIN( SGIStyle )

Listing 2: Lokalisierte Applikation

#include <qapplication.h>
#include <qtranslator.h>
#include <qtextcodec.h>

[...]

int main( int argc, char ** argv){
  QApplication * app = new QApplication( argc, argv );

  QTranslator * translator = new QTranslator( 0 );
  // Lade Übersetzungsdatei /local/lib/app_Sprachkürzel.qm
  translator->load( QString( "app_" ) + QTextCodec::locale(),
                      "/local/lib" );
  app->installTranslator( translator );

[...]
}

Noch mehr Klassen

Hinter den neuen Tools verblasst ein wenig, dass auch das Toolkit Qt selbst mit neuen Klassen aufwarten kann. In erster Linie wäre hier das SQL-Datenbank-Modul zu erwähnen. Nur in der Enterprise-Ausgabe und der Free Edition enthalten bietet es in einer dreistufigen Architektur (Treiber-Ebene, API-Layer und User-Interface-Ebene) Klassen für den Zugriff und die Manipulation von SQL-Datenbanken an.

Datenbanktreiber werden als Plug-ins realisiert und für Oracle, MySQL, PostgreSQL und ODBC mitgeliefert. Ein TDS-Plug-in bietet Unterstützung für das Tabular-Datastream-Protokoll, wie es von Sybase und Microsoft zur Client-Kommunikation benutzt wird.

Für Datenbank-Verbindungen steht die Klasse »QSQLDatabase« zur Verfügung, während SQL-Queries über »QSqlQuery« abgesetzt werden. Die »QSqlCursor«-Klasse wiederum erlaubt das Manipulieren von Tabellen und Ansichten ohne SQL-Statements. Die Datenbank-Widgets wie »QDataTable« oder »QDataBrowser« stehen übrigens auch im Designer zur Auswahl.

Komplett renoviert präsentiert sich der »QTextBrowser«. Er basiert nunmehr auf dem neuen Richtext-Editor »QTextEdit«, der die Klassen »QMultiLineEdit« und »QTextView« obsolet macht.

Detailverbesserungen sind an vielen Stellen spürbar[2]. So kennt »QPicture« jetzt (wenigstens teilweise) auch das SVG-Format und die Unterstützung der nicht-lateinischen Schriftzeichen verbessert sich dank erweiterter Unicode-Implementierung entscheidend. (Unter X11 wird mehrsprachige Darstellung auch deshalb problemloser, weil »QFont« aus vorhandenen Systemfonts einen logischen Font zusammenmischt.) Auch beim Problemkind Drucken hat sich einiges getan.

Die Zeit zwischen der ersten Qt-3-Beta im Mai 2001 und der endgültigen Release hat Trolltech gut genutzt. Viele Fehler, Unstimmigkeiten und Lücken wurden beseitigt, auch wenn längst nicht alles Gold ist, was glänzt. Auch die zwischenzeitlich eher vernachlässigte Dokumentation befindet sich wieder auf dem Weg der Besserung. Interessant für Qt-Neulinge sind die so genannten Walkthroughs, auf der Dokumentationshauptseite[3] unter dem Stichwort “Step-by-step Examples” zu finden: Zeile für Zeile erläutern sie überschaubare Beispielprogramme.

Allerdings erfordern sie wie auch die restliche Dokumentation ausreichende Englischkenntnisse. Mag hier der Aufwand für Übersetzungen sehr hoch sein, unverständlich ist aber, dass auch die mitgelieferten GUI-Tools nicht lokalisiert sind, zumal Trolltech immerhin Angestellte aus etwa einem Dutzend Nationen beschäftigt.

Preis- und Lizenz-Dschungel

Ob Qt kostenfrei unter den Open-Source-Lizenzen GPL oder QPL ([http://www.trolltech.com/developer/licensing/qpl.html]) nutzbar ist oder ob Lizenzkosten fällig werden, hängt vom Betriebssystem und der Lizenz der zu erstellenden Software ab.

Linux/Unix-Open-Source-Projekte für X11 benutzen die (im Sourcecode unter [ftp://ftp.troll.no/pub/qt/source/] downloadbare) “Free Edition”. Für Embedded-Open-Source-Projekte steht Qt/Embedded nur unter der GPL bereit. Nicht-kommerzielle Software-Entwicklung unter Windows wird von der kostenfreien “Non Commercial Edition” abgedeckt, die jedoch keinen Quellcode enthält. Die MacOS-X-Version ist grundsätzlich kostenpflichtig.

Wie für Windows- und Unix-Betriebssysteme gibt es Qt für den kommerziellen Einsatz unter MacOS ebenfalls in zwei Ausgaben: als “Professional” und als “Enterprise Edition”. Der ersten fehlen die so genannten Module ([http://www.trolltech.com/products/qt/modules.html]), etwa die XML-, die Datenbank- oder die Spreadsheet-Klassen.

Kommerzielle Lizenzen, deren Inhalt sich im Desktop- und im Embedded-Bereich unterscheidet, verkauft Trolltech pro Entwicklerplatz; die Preise sind gestaffelt und hängen von der Anzahl der gewünschten Betriebssysteme ab. Eine Einzellizenz für ein Desktop-Betriebssystem kostet 1550 US-Dollar (Professional) beziehungsweise 1950 US-Dollar (Enterprise). Nähere Informationen sind unter [http://www.trolltech.com/purchase/qtpricing.html] und [http://www.trolltech.com/purchase/embeddedpricing.html] zu finden.

Infos

[1] Rafael Peregrino: “Klein-Delphi”, Linux-Magazin 12/01, S. 111 ff.

[2] [http://www.trolltech.com/developer/changes/3.0.0.html]

[3] [http://doc.trolltech.com/3.0/]

LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben