Wer sich ein wenig mit dem Qt-Toolkit beschäftigt hat, stellt überrascht fest, wie wenig Zusatzwissen erforderlich ist, um Software für die freie PDA-Oberfläche OPIE zu schreiben. Selbst für Programmiereinsteiger bietet das Projekt ein dankbares Betätigungsfeld.

Ob der PDA von Haus aus mit Linux und der Benutzeroberfläche Qtopia ausgestattet ist oder man Open Zaurus[2] mit dem Open Palmtop Integrated Environment (OPIE[1]) installiert – in beiden Fällen sieht es zunächst so aus, als ob an Software für den Handheld kein Mangel herrschen dürfte: Schließlich benutzen viele grafische Programme für den Linux-Desktop ebenfalls die Qt-Bibliothek der Firma Trolltech. Die könnte man gegen Qt/e, die Qt-Ausgabe für Embedded Devices, linken und für den ARM-Prozessor des Zaurus-PDA crosskompilieren – fertig.

Doch so einfach ist das leider nicht: Zum einen verfügt der PDA bei weitem nicht über die Rechenpower und den Speicherplatz eines PCs oder Macs. Zum anderen lassen sich die meisten GUI-Programme für den Linux-Desktop nur dann sinnvoll bedienen, wenn man sie auf einem PC-Monitor anzeigt. Eins zu eins auf das Bildschirmchen des PDA verlegt, nerven sie den User mit Scroll-Orgien und schlimmeren Verstößen gegen den Grundsatz der Usability. So manche Anwendung ist sogar nur auf einem PDA sinnvoll und sollte deshalb direkt mit Blick auf diese Zielplattform programmiert werden.

Anwendungsentwicklung für den PDA kann also nicht einfach nur ein Abfallprodukt der Software-Entwicklung für den Desktop sein. Doch auch wenn das Ausgabegerät andere Ansprüche ans Softwaredesign stellt als ein PC oder Mac, muss man bei der Einarbeitung ins Entwicklungswerkzeug nicht alles doppelt lernen.

Arbeitsplatz einrichten

Aufgrund der begrenzten Ressourcen eines PDA findet die Programmierarbeit auf einem Desktop-Rechner (PC oder Mac) statt. Dort gilt es zunächst, sich eine passende Arbeitsumgebung zu schaffen: Damit man das PDA-Programm während des Entwicklungsprozesses testen kann, ist ein Emulator nötig. Einer mit dem Namen »qvfb« (Qt Virtual Framebuffer) liegt dem Qt/e-Paket[3] bei (Abbildung 1).

Sobald ein neu entwickeltes Programm stabil läuft und die wichtigsten Funktionen aufweist, kann man es für den PDA crosskompilieren und das dabei erzeugte Binary auf dem Handheld installieren. Dieses Vorgehen erlaubt es, die gewohnten C++-Entwicklungstools wie »gcc«, »gdb« und »valgrind« (zum Aufspüren von Speicherlecks und anderen Programmfehlern)[4] zu benutzen und die Software erst im letzten Schritt zum Testen auf den PDA zu kopieren.

Beim Verfassen des Quellcodes können natürlich Editoren wie »vi« oder »emacs« zum Einsatz kommen. Mit KDevelop 3 ([5],[6]), das vermutlich zeitgleich mit KDE 3.2 veröffentlicht wird, doch schon jetzt sehr stabil ist, steht aber eine integrierte Entwicklungsumgebung bereit, die OPIE direkt unterstützt.

Wie bei vielen anderen Projekten bekommt man auch die neueste OPIE-Version aus dem CVS (siehe Kasten “OPIE aktuell”). Sie enthält Patches für Qt/e, sodass hier noch etwas Arbeit anfällt. Wer nur mal schnell in OPIE hineinschnuppern will oder sich die Frustration einer nicht kompilierenden CVS-Version ersparen möchte, greift auf den Tarball »opie-devel-g++3_x86_0.9.1-ml2 .tar.gz« von[7] zurück.

Er enthält ein für OPIE angepasstes Qt/e sowie die OPIE-Bibliotheken, beides jedoch in nicht mehr ganz taufrischen Versionen. Ganz ohne Nacharbeit geht es aber auch hier nicht: Ist kein »distcc«[11] zur verteilten Kompilation von C/C++-Code installiert, muss man in der Datei »qt-2.3.4-beta2/configs/linux-x86-g++-shared« beim Setzen von »SYSCONF_CXX«, »SYSCONF_CC«, »SYS-CONF_LINK« und »SYSCONF_LINK_ SHLIB« jeweils das Wort »distcc« entfernen. Der Pfad zum »qt-2.3.4-beta2«-Verzeichnis gehört dann noch in die Umgebungsvariable »QTDIR« – dann startet die Übersetzung in diesem Ordner mit:

./configure -qconfig qpe -depths 8,16,24 U -qvfb -vnc -system-jpeg -system-libpng U -system-zlib -gif -no-xft
make

Mit »uic-qt2« von[7] verlinkt nach »$QTDIR/bin/uic« (wer einmal dabei ist, kann auch »qvfb-qt2« von[7] mit »$QTDIR/bin/qvfb« verknüpfen) geht es ans Erstellen der OPIE-Bibliotheken. Zunächst ist die Variable »LD_LIBRARY _PATH« auf »$QTDIR/lib« zu setzen, damit das neukompilierte Qt/e-Binary auch gefunden wird. Das weitere Vorgehen wird in der Datei »opie/README .NEWBUILD« im Einzelnen beschrieben. Da die von »opie/def-configs/opie« nach »opie/.config« kopierte Grundkonfiguration für den Anfang ausreicht, kann man den letzten, im Readme aufgeführten Schritt (»make menuconfig«) weglassen und sofort »make« starten.

Damit stehen nun zwar die Bibliotheken und die entsprechenden Werkzeuge für den PC bereit. Da der PDA jedoch keinen Intel-kompatiblen, sondern einen ARM-Prozessor enthält, darf dafür gedachte Software nicht gegen PC-Libraries gelinkt werden. Die Qt/e- und OPIE-Bibliotheken sind daher noch einmal für den PDA zu kompilieren – mit einem Crosscompiler[10]. Dazu kopiert man am besten das gesamte »qt-2.3.4-beta2«-Verzeichnis etwa nach »qt-2.3.4-beta2_pda«.

Abbildung 1: Ohne zu testendes Programm sieht »qvbf« einfach nur schwarz.

cvs -d:pserver:anoncvs@cvs.handhelds.org:U /cvs login

cvs -d:pserver:anoncvs@cvs.handhelds.org:U /cvs co opie
export OPIEDIR=/Pfad/zu/opie/

cd qt-2.3.5; export QTDIR=`pwd`
cat $OPIEDIR/qt/qte234-for-opie091-U gfxraster.patch | patch -p0

cp $OPIEDIR/qt/qconfig-qpe.h $QTDIR/src/U tools

export PATH=$PATH:$QTDIR/bin
cd $OPIEDIR
make clean
make

cvs -d:pserver:anoncvs@cvs.handhelds.org: /cvs co -r OPIE_BRANCH_0_99 opie
export OPIEDIR=/Pfad/zu/opie/
cd $OPIEDIR
mkdir bin libsql development
cp opie-release-1.0.config .config
make oldconfig
make

export QMAKESPEC=$OPIEDIR/mkspecs/U linux-g++/

include ( $(OPIEDIR)/include.pro )

Zielplattform PDA oder PC?

Je nachdem, ob die auf dem PC auszuführende Testversion eines OPIE-Programms übersetzt oder eine Ausgabe für den PDA crosskompiliert werden soll, sind diverse Umgebungsvariablen – insbesondere »QTDIR« – anzupassen. Um dabei nicht durcheinander zu kommen, überlässt man das am besten einem Skript wie in Listing 1: Ohne Argument aufgerufen setzt es die Variablen für eine PC-Kompilation. Erhält es ein beliebiges Argument, richtet es die Umgebung für einen Crosscompiler-Lauf ein. Ganz nebenbei setzt das Skript auch die Variablen »OPIEDIR«, die das Oberverzeichnis von OPIE enthält, und »TMAKEPATH«, die auf das zum Compiler passende Konfigurationsverzeichnis des ebenfalls in »opie-devel-g++3_x86_0.9.1-ml2.tar.gz« enthaltenen Hilfsprogramms »tmake« zeigt.

01 #!/bin/bash
02 export OPIEDIR=$HOME/opie/opie
03 if [ "x${1}x" = "xx" ]; then
04     export QTDIR=$HOME/qt-2.3.4-beta2
05     export TMAKEPATH=$HOME/tmake/1.8/lib/qws/linux-generic-g++
06 else
07     export QTDIR=$HOME/qt-2.3.4-beta2_pda
08     export TMAKEPATH=$HOME/tmake/1.8/lib/qws/linux-sharp-g++
09 fi
10 export PATH=$QTDIR/bin:$HOME/tmake/1.8/bin:$PATH
11 export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH

Das Grundgerüst

Nach diesen Vorarbeiten kann es ans Erstellen eines ersten OPIE-Programms gehen. Es soll Informationen über eine Datei anzeigen, genauer gesagt die Dateigröße, das Datum der letzten Bearbeitung, den Besitzer und die Zugriffsrechte – also Funktionalität, die zum Beispiel ein Dateimanager braucht.

Dazu startet es einen Dialog, der die Datei- und Verzeichnisstruktur anzeigt. Sucht der Benutzer darin eine Datei aus, erscheint ein neuer Dialog, der die Datei-Informationen darstellt. Das Programm, im Quellcode unter[12] zu finden, heißt »testapp«. Entsprechend legt man ein Projektverzeichnis gleichen Namens an, in dem die Projektdatei »testapp.pro« (Listing 2) und der Quellcode ihren Platz finden.

»testapp.pro« legt in den Zeilen 4 und 5 fest, welche Dateien zum Projekt gehören. Als OPIE-Programm muss das zu erstellende Binary (»TARGET«) »testapp« gegen die OPIE-Bibliothek »libopie« gelinkt werden, was der Linker dank »LIBS += -lopie« erfährt.

Erhält das Tool »tmake« die Projektdatei als Argument, generiert es daraus ein Makefile. Wer auf seinem System bereits eine Entwicklungsumgebung für eine Desktopversion von Qt hat, kann alternativ auf das neuere Werkzeug »qmake« zurückgreifen, das ab Qt 3.0 mit dabei ist (siehe auch Kasten “OPIE aktuell”). Sollte es wider Erwarten Probleme dabei gaben, enthält der Tarball »testapp.tar .bz2« von[12] ein funktionierendes Makefile, in dem allerdings noch diverse Pfade ans eigene System angepasst werden müssen.

01 TEMPLATE     = app
02 CONFIG       = qt warn_on release
03 DESTDIR      = $(OPIEDIR)/bin
04 HEADERS      = mainwindow.h
05 SOURCES      = main.cpp mainwindow.cpp
06 INCLUDEPATH += $(OPIEDIR)/include $(OPIEDIR)/libopie
07 DEPENDPATH  += $(OPIEDIR)/include $(OPIEDIR)/libopie
08 LIBS        += -lqpe -lopie
09 TARGET       = testapp

01 #include <qpe/qpeapplication.h>
02 #include "mainwindow.h"
03 
04 int main(int argc, char **argv).
05 {
06    QPEApplication a(argc, argv);
07    MainWindow mw;
08    a.showMainWidget(&mw);
09    return a.exec();
10 }

Die Hauptsache

In Listing 3 geht es dann endlich ans Programmieren: Die Applikation selbst wird als Objekt des Typs »QPEApplication« erstellt. Sie zeigt ein Objekt vom Typ »MainWindow« an. Diese Klasse ist die einzige selbst geschriebene Klasse des Programms. Sie wird aus dem Tarball von[12] in der Datei »mainwindow.cpp« implementiert, die wir im Weiteren nur in Auszügen zitieren.

»MainWindow« stammt von der Qt-Klasse »QMainWindow« ab, die das Hauptfenster einer GUI-Applikation implementiert. Objekte dieser Klasse können Toolbars, eine Statusleiste und eine Menüleiste enthalten. Der Übersichtlichkeit halber bekommt das Beispielprogramm lediglich eine Menüleiste:

QPEMenuBar *menubar = new QPEMenuBar( this );

Bei »QPEMenuBar« handelt es sich um eine speziell für PDAs erweiterte Klasse, die von »QMenuBar« erbt. (Deren Name rührt daher, dass Trolltechs Qtopia-Oberfläche für PDAs früher einmal QPE – Qt Palmtop Environment – hieß.)

Die darauf folgenden Zeilen (Listing 4) implementieren das Menü und die damit verbundenen Aktionen: Zuerst wird ein neues Menü erzeugt und in der zweiten Zeile in die Menüleiste eingebaut. An dieser Stelle erhält es den Namen »File«. Diesen Text bekommen später die Nutzer des Programms zu Gesicht (Abbildung 3). Die Bedeutung des Befehls »tr()«, der hier und an weiteren Stellen im Quelltext auftritt, erklärt der Kasten “Übersetzungen”.

Ein Menü soll auf Anwahl Unterpunkte auflisten, die jeweils eine Aktion auslösen. Dazu erzeugt man eine Instanz »a« der Klasse »QAction«. Eine solche »QAction« repräsentiert eine Aktion in einer Menüleiste oder in einer Toolbar. In diesem Fall ist ein Menü-Eintrag namens »New« gefragt, der auf seine Anwahl hin einen Dialog öffnet, in dem der Benutzer eine Datei aussucht.

Ein Bild sagt mehr als tausend Worte, daher stellt OPIE zahlreiche Icons bereit, mit denen sich zum Beispiel Menü-Einträge verschönern lassen. Dank »Resource::loadPixmap( “new” )« steht neben dem Eintrag »New« ein kleines Bild, das die Aktion – das Aussuchen einer Datei – illustriert.

Abbildung 2: »make menuconfig« sorgt dafür, dass die nicht-kompilierenden OPIE-Bestandteile beim Übersetzen übersprungen werden.

Signale und Slots

Die vorletzte Zeile in Listing 4 zeigt einen der wichtigsten Tricks bei der Programmierung mit Qt: den Signal-Slot-Mechanismus. Jedes von der Klasse »QObject« abgeleitete Objekt (das sind unter anderem alle GUI-Elemente), sendet mit »emit« (oft automatisch) Signale aus, wenn etwas passiert. So emittiert eine Aktion, die einen Menüpunkt repräsentiert, das Signal »activated()«, wenn sie aktiviert (angewählt) wird. Solche Signale fangen Slots auf, die mit dem jeweiligen Signal verknüpft sind.

Im Beispiel reagiert der Slot »slotfileNew()« derselben (»this«) Klasse »MainWindow« auf das »activated()«-Signal. Dieser Slot ist eine ganz normale Funktion, die auch direkt aufrufbar ist. Dass sie wie in Listing 4 mit Signalen verknüpft werden kann, dafür sorgt ihre Kennzeichnung als Slot in der Header-Datei »mainwindow.h«:

private slots:
    void slotfileNew();

Die Implementation der Funktion »MainWindow::slotfileNew()« in »mainwindow.cpp« legt fest, was passiert, wenn ein User den Menüpunkt »New« aktiviert: Ein Dateidialog wird erzeugt (Abbildung 4).

Der Signal-Slot-Mechanismus macht die Kommunikation zwischen Objekten sehr einfach, da diese nichts voneinander wissen müssen. Zudem ist er vollkommen typensicher (typesafe); es lassen sich alle Arten und eine beliebige Anzahl von Daten verarbeiten.

menubar->insertItem( tr( "File" ), file );

label.setText( "The City %1 has %2 inhabitants").arg(cityName).arg(cityInhabitants);

QString city_text = tr( "The City" ) + cityName + tr( "has" ) + cityInhabitants + tr( "inhabitants" );
label.setText( city_text );

Eine Klasse aus dem OPIE-API

Bis hierhin kamen – außer dem eingebundenen Icon – noch keinerlei Klassen und Funktionen aus dem OPIE-API selbst zum Einsatz. Das ändert sich mit dem Dateidialog, den »slotfileNew()« auf den Bildschirm zaubert (Abbildung 4). Diesen Dialog, aus dem der User bequem eine Datei aussuchen kann, implementiert die Klasse »OFileDialog«. Klickt der Benutzer anschließend auf »OK«, speichert die folgende Codezeile den Rückgabewert der »OFileDialog«-Funktion »getOpenFileName()«, also den Dateinamen der ausgewählten Datei mit vollem Pfad, in einer privaten Klassenvariablen der »MainWindow«-Klasse:

fileName=OFileDialog::getOpenFileName( OFileSelector::EXTENDED , QDir::homeDirPath() );

Im nächsten Schritt geht es darum, die gewünschten Datei-Informationen auszulesen. Dazu hält Qt/e die Klasse »QFileInfo« bereit. Mit ihr sind etwa Dateigröße und Berechtigungen sehr einfach aus einer Datei extrahierbar.

Die Klasse »MainWindow« speichert die Dateigröße in der privaten Klassenvariablen »fSize« vom Typ »unsigned int«, den Besitzer im Q-String »fOwner«, die Gruppe im Q-String »fGroup«, den Dateinamen im Q-String »fileName« sowie Datum und Zeit der letzten Bearbeitung in »fLastMod«, die ihren Typ der extra für solche Zwecke gedachten Qt-Klasse »QDateTime« verdankt.

Listing 5 zeigt, wie diese Variablen mit den zur gewünschten Datei passenden Werten zu füllen sind. Diese Aufgabe übernimmt die »MainWindow«-Funktion »getFileInfos«, die beim Aufruf als Argument den jeweiligen Dateinamen übergeben bekommt.

Die so gewonnenen Informationen müssen noch dargestellt werden. Dafür sorgen die Zeilen 64 bis 68 in der Datei »mainwindow.cpp«. Sie schreiben den Inhalt der jeweiligen Variablen (und eine Erklärung) auf je eines von fünf zuvor erstellten Objekten vom Typ »QLabel«:

fileNameLabel->setText( tr( "Filename: %1").arg( fileName ) );

Um die fünf Label gleichmäßig über den verfügbaren Platz zu verteilen (Abbildung 5), packt man eins nach dem anderen in ein »QVBoxLayout«. Es platziert die ihm zugewiesenen Widgets vertikal:

QVBoxLayout *v_layout = new QVBoxLayout( mainWidget );
[...]
v_layout->addWidget( fileNameLabel );

Die Klasse »QLabel« bietet viele Möglichkeiten, um die Textdarstellung auf den Labels gesondert zu manipulieren, etwa die Größe oder Art der Schrift oder auch die Ausrichtung zu ändern. Das Beispielprogramm nutzt dies im Falle der Überschrift »LinuxMagazine« in Abbildung 5, die auf einem eigenen Label-Objekt namens »topicLabel« sitzt. Ein

topicLabel->setAlignment( AlignHCenter );

richtet den Text horizontal mittig aus;

QFont f1 ( "times", 18, QFont::Bold );
topicLabel->setFont( f1 );

sorgt dafür, dass die Überschrift in einer 18-Punkt-Times und fett gedruckt erscheint. Ganz ähnlich ist es möglich, beispielsweise den Zeilenumbruch zu kontrollieren oder den Umbruch generell zu verbieten.

01 QPopupMenu *file = new QPopupMenu( this );
02 menubar->insertItem( tr( "File" ), file );
03 QAction *a = new QAction(  tr(  "New" ), Resource:: loadPixmap( "new" ), QString::null, 0, this, 0 );
04 connect( a , SIGNAL( activated() ), this,  SLOT( slotfileNew() ) );
05 a->addTo( file );

01 void MainWindow::getFileInfos( QString fName )
02 {
03     fileInfo.setFile( fName );
04     fSize = fileInfo.size();
05     fOwner = fileInfo.owner();
06     fGroup = fileInfo.group();
07     fLastMod = fileInfo.lastModified();
08 }

Ready, steady, go!

Richtig schön wird das Programmieren erst beim Testen. Dazu darf jetzt endlich der Emulator »qvfb« starten. Statt des ganz zu Beginn schwarzen Fensterinhalts (Abbildung 1) wird demnächst (hoffentlich) die Testapplikation erscheinen. Gegebenenfalls lenkt man die Ausgabe mit

QWS_DISPLAY=QVFb:0

an die richtige Stelle. Hat man das Makefile für das Testprogramm mit »tmake« beziehungsweise »qmake« erstellt, reicht bereits ein »make« im Projektverzeichnis, um den Kompiliervorgang anzustoßen. Doch selbst, wenn dabei alles glatt geht, dürfte sich so mancher wundern, dass das Projektverzeichnis anschließend gar kein Binärprogramm enthält. Dieses befindet sich nämlich in »$OPIEDIR/bin«. Startet man es mit der Option »-qws«, füllt sich »qvfb« mit Leben (Abbildung 3).

Wer sich nach diesem Exkurs an eigene OPIE-Projekte herantraut, wird bei den dann sicher auftretenden Problemen nicht allein gelassen: Die OPIE-Homepage bietet neben weiteren Informationen auch die Möglichkeit, sich bei der »opie-devel«-Mailingliste anzumelden, auf der sich OPIE-Entwickler austauschen und weiterhelfen. (pju)

Abbildung 3: Ruft man das Beispiel von der Kommandozeile auf, landet die Ausgabe im »qvfb«.

Abbildung 4: Diesen Dateidialog stellt das OPIE-API mit der Klasse »OFileDialog« zur Verfügung.

Abbildung 5: Die Datei-Informationen präsentiert das Programm auf vertikal angeordneten Q-Labels.