Lektion 1: Qt Version von "Hello World"
Autoren: tuxipuxi, anda_skoa
Beipieldatei: lektion1.cpp
Code:
#include <qapplication.h>
#include <qpushbutton.h>
int main( int argc, char* argv[] )
{
QApplication app( argc, argv );
QPushButton helloworld( "Hello World", 0 );
helloworld.resize( 100,30 );
app.setMainWidget( &helloworld );
helloworld.show();
return app.exec();
}
Nun betrachten wir das Programm Zeile für Zeile:
Code:
#include <qapplication.h>
Dieser Header deklariert die Klasse QApplication.
Eine Instanz der Klasse QApplication wird benötigt, wenn das Programm das Eventhandling von
Qt benutzen möchte.
Events benötigt man wenn man
[list=a][*] Widgets benutzt, d.h. wenn man eine GUI machen möchte[*] Sockets benutzt, d.h. wenn man Netzwerkkommunikation machen möchte[*] QProcess benutzt, d.h. wenn man andere Programme als Kindprozesse starten möchte[/list=a]
In diesem Fall trifft (a) zu.
Code:
#include <qpushbutton.h>
Dieser Header deklariert die Klasse QPushButton.
Ein QPushButton ist ein klassischer Button.
Code:
int main( int argc, char *argv[] )
Beginn der normalen main Funktion eines C++ Programms.
Code:
QApplication app( argc, argv );
Wir erzeugen unsere QApplication Instanz und verwenden als Parameter die Kommandozeilen Argumente
des Programms.
Qt definiert ein paar mögliche Argumente und benutzt sie, wenn sie in argv enthalten sind.
Die verbleibenden Argumente verhält man über die Methoden argc() bzw. argv() der QApplication Instanz.
Code:
QPushButton helloworld( "Hello World", 0 );
Dies erzeugt einen QPushButton, dessen Eigenschaften wir mit Hilfe seiner Methoden ändern können.
Das erste Argument gibt den Text an, der im QPushButton stehen soll, der zweite das Parent Widget.
Das Parent Widget ist das GUI Element, in dem das neue Widget enthalten sein soll.
Hier ist der Parent 0, d.h. der Button ist hat keinen Parent.
Hat ein QObject (das gilt nicht nur für QWidgets) ein Parent QObject, dann wird der Parent alle seine
Kindobjekte löschen, wenn er selbst gelöscht wird.
Das ist vorallem bei Widgets praktisch, weil man nicht alle Elemente eines Fenster einzeln löschen muss,
sondern es reicht, das Fenster zu löschen.
Code:
helloworld.resize( 100,30 );
Die Methode resize eine QWidget ändert seine Größe. Die Parameter sind die Breite (width) und die Höhe (height).
Der Button wird also auf 100 Pixel Breite und 30 Pixel Höhe gesetzt.
Code:
app.setMainWidget( &helloworld );
Setzt unseren QPushButton helloworld als MainWidget der Applikation. Normalerweise hat jede Qt GUI-Applikation ein MainWidget.
Wird dieses geschlossen, beendet sich auch die QApplication.
Ein Widget ist nach seiner Erzeugung nicht automatisch sichtbar.
Es muss erst die Methode show aufgerufen werden.
Widgets die eine Parent haben, werden sichtbar, wenn der Parent sichtbar wird, außer der Parent
war bei Erzeugung des Kindwidgets bereits sichtbar.
Hier übergeben wir der Qt-Application ( app ) das Kommando.
Sobald diese beendet wird, liefert app einen Rückgabewert und die main Funktion wird ebenfalls beendet.
Kompilierung:
Um diese Datei zu kompilieren, braucht man ein paar Argumente für den C++ Compiler.
Da wir Qt Headerdateien verwenden, brauchen wir den Pfad an dem sie liegen.
Da wir anschliessend mit der Qt Bibliothek linken wollen, brauchen wir auch den Pfad der Bibliothek.
Um die beiden Pfad zu erhalten, rufen wir locate auf
Zitat:
#> locate qapplication.h
/usr/lib/qt-3.0.3/include/qapplication.h
/usr/share/doc/qt-devel-3.0.3/html/qapplication.html
Das zweite ist der Pfad der Dokumentation, aber den brauchen wir nicht.
Unsere Qt Header sind hier also in /usr/lib/qt-3.0.3/include
Zitat:
#> locate libqt
/usr/lib/qt-3.0.3/lib/libqt-mt.so.3
/usr/lib/qt-3.0.3/lib/libqt-mt.so.3.0
/usr/lib/qt-3.0.3/lib/libqt-mt.so.3.0.3
/usr/lib/qt-3.0.3/lib/libqt.so.3
/usr/lib/qt-3.0.3/lib/libqt.so.3.0
/usr/lib/qt-3.0.3/lib/libqt.so.3.0.3
/usr/lib/qt-3.0.3/lib/libqt-mt.so
/usr/lib/qt-3.0.3/lib/libqt.so
Der Pfad zur Bibliothek ist also /usr/lib/qt-3.0.3/lib
Die Qt Bibliothek liegt hier sowohl mit (libqt-mt.so) Thread Unterstützung vor, also auch ohne (libqt.so).
Welche von beiden benutzt wird, ist für unser Beispiel nicht wichtig.
(Die Pfade sind von System zu System unterschiedlich)
Der Aufruf lautet nun wie folgt:
Zitat:
#> g++ -o lektion1 lektion1.cpp -Wall -I/usr/lib/qt-3.0.3/include -L/usr/lib/qt-3.0.3/lib -lqt-mt
Zur Erklärung:
- g++ : der C++ Compiler unter Linux.
- -o lektion1 : der Name, den das Programm haben soll
- lektion1.cpp : Unsere Quelltextdatei
- -Wall : aktiviert alle Warnung des Kompilers
- -I/usr/lib/qt-3.0.3/include: Angabe eines Pfades für Headerdateien (das I ist ein großes i)
- -L/usr/lib/qt-3.0.3/lib : Angabe eines Pfads für Bibliotheken
- -lqt-mt : die Bibliothek, mit der unser Programm gelinkt werden soll (das l ist ein kleines L)
- Der Aufruf mit der Qt ohne Threadunterstütztung unterscheidet sich nur in diesem letzten Argument: -lqt
Treten beim Kompilieren und Linken keine Fehler auf, kann das Programm nun gestarte werden:
Lektion 2: Benutzung von Signals und Slots
Autor: anda_skoa
Der Button aus Lektion 1 hat noch keine Funktion.
Es wäre doch fein, wenn ein Klick auf den Button das Fenster schliessen
würde.
Das geht ganz leicht, mit nur einem weiteren Befehl:
lektion2.cpp
Code:
#include <qapplication.h>
#include <qpushbutton.h>
int main( int argc, char* argv[] )
{
QApplication app( argc, argv );
QPushButton helloworld( "Hello World", 0 );
helloworld.resize( 100,30 );
app.setMainWidget( &helloworld );
QObject::connect(&helloworld, SIGNAL(clicked()), &app, SLOT(quit()));
helloworld.show();
return app.exec();
}
Betrachten wir die zusätzliche Zeile:
Code:
QObject::connect(&helloworld, SIGNAL(clicked()), &app, SLOT(quit()));
Wir sehen im wesentlichen zwei Sachen:[list=a][*] den Aufruf der offensichtlich statische Methode connect der Klasse QObject[*] die Anwendung von zwei Makros: SIGNAL und SLOT[/list=a]
QObject ist die Basis
aller Klassen, die in Qt an Events beteilgt sind.
In der Sektion "Static Public Members" finden wir auch die oben benutze
Funktion:
Code:
bool connect ( const QObject * sender, const char * signal, const QObject *
receiver, const char * member )
Was macht nun diese Methode?
Sie verbindet ein Signal eines Senderobjektes mit einem Slot eines
Empfängerobjektes.
Signale und Slots sind eine Eigenheit von Qt.
Sie erlauben das verbinden zwei Objekten, ohne dass sich die beiden Partner
kennen müssen.
Nur der Verbinder muss beide kennen.
Signal und Slots sind eine Art lokales Event.
Jede QObject Subklasse kann Signale aussenden und Signale empfangen.
Wenn ein Signal nicht verbunden ist, verpufft es einfach.
Ein Signal kann mit mehreren Slots verbunden sein.
In diesem Fall werden alle Slots in zufälliger Reihenfolge aktiviert, also
ausgeführt.
In unserem Beispiel verknüpfen wir das Signal clicked() des QPushButtons mit
dem Slot quit() der QApplication Instanz.
Signale und Slots befinden sich in der Qt Dokumentation immer in eigene
Sektionen der jeweiligen Klassen.
clicked() ist in dem Fall nicht direkt in QPushButton sondern bereits in der
Basisklasse QButton deklariert.
Wie die leere Klammer andeutet, hat das Signal clicked() keinen
Parameter, transportiert also keine Daten.
Darum können wir es nur mit einem Slot verbinden, der keinen Parameter
erwartet.
Glücklicherweise ist quit() genau so ein Slot. :)
Die Parameter von Signal und Slot müssen immer in ihrem Typ übereinstimmen.
Das wird allerdings erst zur Laufzeit überprüft, der Compiler meldet also
keinen etwaigen Fehler. So etwas sieht man dann auf der Konsole, von der aus
das Programm gestarte wurde.
Dieser Effekt kann leicht demonstiert werden, wenn man clicked()
gegen toggled(bool) austauscht.
Unsere Programmzeile würde in diesem Fall so aussehen:
Code:
QObject::connect(&helloworld, SIGNAL(toggled(bool)), &app, SLOT(quit()));
Kompilierung
Die Kompilierung erfolgt wie in der ersten Lektion:
Zitat:
#> g++ -o lektion2 lektion2.cpp -Wall -I/usr/lib/qt-3.0.3/include -L/usr/lib/qt-3.0.3/lib -lqt-mt
Wenn das Programm nun ausgeführt wird, wird bei einem Klick auf den Button
das Programm beendet.
Durch den Klick sendet der Button sein clicked() Signal aus.
Anders als in Lektion 1 ist dieses Signal nun mit quit() der
QApplication verdunden. Darum wird von Qt diese Methode ausgeführt, was die
QApplication dazuveranlasst, sich zu beenden.
Lektion 3: Benutzung eines eigenen Widgets
Autor: anda_skoa
In dieser Lektion haben wir es nun mit drei Dateien zu tun:
lektion3.cpp: enthält wie immer die main Funktion
qttutwidget.h: enthält die Deklaration einer Beispielwidgetklasse
qttutwidget.cpp: enthält die Implementation des Widgets
lektion3.cpp
Code:
#include <qapplication.h>
#include <qpushbutton.h>
#include "qttutwidget.h"
int main( int argc, char* argv[] )
{
QApplication app( argc, argv );
QtTutWidget helloworld( "Hello World", 0 );
helloworld.resize( 100,30 );
app.setMainWidget( &helloworld );
helloworld.show();
return app.exec();
}
qttutwidget.h
Code:
#ifndef QTTUTWIDGET_H
#define QTTUTWIDGET_H
#include <qlabel.h>
class QtTutWidget : public QLabel
{
public:
QtTutWidget(QString text, QWidget* parent=0, const char* name=0);
};
#endif
qttutwidget.cpp
Code:
#include "qttutwidget.h"
QtTutWidget::QtTutWidget(QString text, QWidget* parent, const char* name)
: QLabel(text, parent, name)
{
}
Erklärungen der Änderungen
Unser Hauptprogramm sieht fast wie das aus Lektion 1 aus.
Es gibt hier nur zwei Unterschiede:
Code:
#include "qttutwidget.h"
Hier inkludieren wir den Header unseres neuen Widgets.
Code:
QtTutWidget helloworld( "Hello World", 0 );
Und hier erzeugen wir es. Der Typ von helloworld ist nun nicht mehr QPushButton sondern unser
neues Widget.
Sehen wir uns die beiden neuen Dateien an:
Code:
#ifndef QTTUTWIDGET_H
#define QTTUTWIDGET_H
#endif
Hier sehen wir eine spezielle Konstruktion aus Preprozessor Direktiven.
Wir bräuchten sie hier nicht, aber im Normallfall gehört so etwas in ein Headerfile, um es vor
Mehrfachinkludierung zu schützen.
Wie funktioniert das?
Die erste Zeile prüft, ob ein gewisses Symbol (QTTUTWIDGET_H) definiert ist.
ifndef (if not defined) wird war, wenn das Symbol nicht definiert ist.
Alle Zeilen bis zum endif werden darum vom Preprozessor ausgeblendet, wenn das QTTUTWIDGET_H
definert ist.
Genau das passiert in der zweiten Zeile.
Wird der Header zum erstenmal inkludiert, ist das Symbol nicht bekannt, der Header wird also vollständig
übernommen, aber gleichzeitig wird durch das define das Symbol bekannt gemacht.
Wird der Header nun ein weiteres Mal inkludiert, kennt der Preprozessor das Symbol und übergeht
den Header.
Code:
#include <qlabel.h>
Der Header für QLabel wird inkludiert.
Das tun wir, weil das die Basisklasse unsere Widgets sein wird.
Code:
class QtTutWidget : public QLabel
Unser Widget mit dem Klassennamen QtTutWidget wird deklariert und wir geben an, dass es von QLabel
abgeleitet ist.
Code:
QtTutWidget(QString text, QWidget* parent=0, const char* name=0);
Der Konstruktor unseres Widgets wird deklariert. So einen ähnlichen gibt es auch von QLabel.
Der erste Parameter ist der darzustellende Text, der zweite das Parentwidget (siehe Lektion 1)
und der dritte ist der Name des Objekts (alle QObject Instanzen können einen Namen haben).
Den zweiten und dritten Parameter haben wir mit einem Standardwert (=0) ausgestattet, das erlaubt uns
diese Parameter nicht unbedingt angeben zu müssen.
Code:
#include "qttutwidget.h"
In der cpp Datei inkludieren wir natürlich den zugehörigen Header.
Code:
QtTutWidget::QtTutWidget(QString text, QWidget* parent, const char* name)
: QLabel(text, parent, name)
{
}
Die Implementation unseres Konstruktors.
Sie hat einen leeren Funktionskörper, weil wir nichts spezielles tun möchte.
Die Parameter werden ungeändert an den Konstruktor der Basisklasse weitergegeben.
Erstellung
Die Kommandos zur Programmerstellung werden nun in zwei Bereiche getrennt, die eigentliche Kompilierung
und das Linken.
Das Kompilieren erzeugt aus dem Quellcode einen binären Maschinencode, das Linken verbindet solche Dateien
dann zu einem Programm.
Zitat:
#> g++ -c -o lektion3.o lektion3.cpp -Wall -I/usr/lib/qt-3.0.3/include
Kompiliert lektion3.cpp in ein Objectfile. Da wir in diesem Schritt nicht linken, brauchen wir
keine Linkeranweisungen.
Das -c sagt dem Compiler, dass wir nur kompilieren wollen.
Zitat:
#> g++ -c -o qttutwidget.o qttutwidget.cpp -Wall -I/usr/lib/qt-3.0.3/include
Kompiliert die Widgetklasse.
Jetzt noch linken:
Zitat:
#> g++ -o lektion3 lektion3.o qttutwidget.o -Wall -L/usr/lib/qt-3.0.3/lib -lqt-mt
Die Eingangsdateien des Linkerschritts sind nun die Resultate der Kompilierschritte.
Hier braucht man wieder die Linkeranwesiungen, kann aber diesmal die -I Angabe weglassen.
Lektion 4: Arbeiten mit Makefiles
Autor: anda_skoa
Wenn wir, wie in Lektion 3, ein Projekt auf mehrere Dateien aufgeteilt haben, brauchen wir ein Linkerkommando und pro CPP Datei ein Compilerkommando.
Außerdem müssen wir uns darum kümmern, welche Dateien neu kompiliert werden müssen, wenn wir eine Datei ändern.
Die Änderung einer CPP Datei erfordert nur, dass diese neu kompiliert wird, eine Änderung eines Headers
erfordert potentiell die Neukompilierung jeder CPP Datei, die diesen Header direkt oder indirekt (über einen anderen Header) inkludiert.
Abhilfe für diese Problematik schaffen uns Makefiles.
Ein Makefile ist eine Steuerdatei für das make Programm.
Makefiles bestehen aus einer Listen von Regeln, die die Reihenfolge der auszuführenden Befehle angibt.
Eine Regel ist wie folgt aufgebaut
(<tab> entspricht einem Tabulator, d.h. im Editor die Tabulator-Taste drücken)
Code:
Name: Abhängigkeiten
<tab>Kommando
.
.
.
<tab>Kommando
Der Name oder Target einer Regel ist im Makefile eindeutig zu wählen.
Eine Regel wird über ihren Namen aktiviert, sowohl innerhalb des Makefiles als auch von außerhalb, also wenn man make aufruft.
Wird beim Aufruf von make kein Name angegeben, wird die erste Regel im Makefile aktiviert.
Bei der Aktivierung werden zuerst die Abhängigkeiten geprüft.
Ist eine Abhängigkeit der Name einer weiteren Regel, wird diese Regel aktiviert.
Ist die Abhängigkeit eine Datei, wird geprüft, ob das Datum der letzten Änderung jünger ist, als da entsprechende Datum der Zieldatei, die von der Regel erzeugt wird.
Ist das der Fall, werden die Kommandos der Reihe nach ausgeführt.
Eine Regel kann beliebig viele Kommandos haben. Das Ende ist durch eine Leerzeile gekennzeichnet.
Beispiel: Makefile für Lektion 3
Datei Makefile:
Code:
lektion3: lektion3.o qttutwidget.o
<tab>g++ -o lektion3 lektion3.o qttutwidget.o -Wall -L/usr/lib/qt-3.0.3/lib -lqt-mt
lektion3.o: lektion3.cpp qttutwidget.h
<tab>g++ -c -o lektion3.o lektion3.cpp -Wall -I/usr/lib/qt-3.0.3/include
qttutwidget.o: qttutwidget.cpp qttutwidget.h
<tab>g++ -c -o qttutwidget.o qttutwidget.cpp -Wall -I/usr/lib/qt-3.0.3/include
Wir können nun mit
oder einfach nur
Das Programm aus Lektion 3 erstellen lassen und make kümmerst sich darum, welche Kommandos erforderlich sind.
Wie geht make dabei vor?
Zuerst wird die Regel lektion3 aktiviert.
Ihre Abhängigkeiten sind die beiden Targets lektion3.o und qttutwidget.o
Die Namen wurden so gewählt, dass sie wie die zuerzeugenden Dateien heißen, damit man leichter den Überblick behält.
Daher werden also zunächst die beiden abhängigen Regeln aktiviert.
Hat sich im Vergleich zu lektion3.o einer der beiden Dateien lektion3.cpp oder qttutwidget.h geändert, wird lektion3.o neu kompiliert.
Ähnliches gilt für qttutwidget.o
Hat eine der beiden Regeln ihr Kommando ausgeführt, führt nun auch die oberste Regel ihr Kommando aus und linkt das Programm neu.
Variablen
Zur leichteren Übertragbarkeit können in Makefiles auch Variablen verwendet werden.
Die Schreibweise ist dabei ähnlich wie in Shellskripten.
Datei Makefile, diesmal mit Variablen
Code:
QTDIR=/usr/lib/qt-3.0.3
INCLUDES=-I$(QTDIR)/include
LIBS=-L$(QTDIR)/lib -lqt-mt
lektion3: lektion3.o qttutwidget.o
<tab>g++ -o lektion3 lektion3.o qttutwidget.o -Wall $(LIBS)
lektion3.o: lektion3.cpp qttutwidget.h
<tab>g++ -o lektion3.o -c lektion3.cpp -Wall $(INCLUDES)
qttutwidget.o: qttutwidget.cpp qttutwidget.h
<tab>g++ -o qttutwidget.o -c qttutwidget.cpp -Wall $(INCLUDES)
Makefiles generieren mit qmake
Bei vielen Dateien und komplexeren Abhängigkeiten wird das händische Erstellen von Makefiles zu einer schwierigen und zeitaufwendigen Aufgabe.
Was liegt also näher, als nach einem Hilfmittel zu suchen, dass Makefiles erstellen leichter macht.
So ein Tool wird von Qt mitgebracht: qmake
Ganz ohne Steuerdatei geht es damit auch nicht, aber die qmake Projektdateien sind sehr simpel aufgebaut:
lektion3.pro
Code:
TEMPLATE = app
CONFIG += qt thread warn_on
SOURCES = lektion3.cpp qttutwidget.cpp
HEADERS = qttutwidget.h
TARGET = lektion3
Sehen wir uns die Datei genauer an:
Wir möchten ein Makefile für eine Applikation. qmake kennt verschiedene Vorlagen für unterschiedliche Projekttypen:
app - für eine Applikation. Das ist auch die Standardvorlage und wird benutzt, wenn nichts anderes angegeben wird.
lib - für eine Bibliothek
subdirs - erzeugt ein Makefile für eine Projekt, in dem die eigentlichen Projektteile in Unterverzeichnisse des Projektverzeichnisses liegen.
Code:
CONFIG += qt thread warn_on
Wir wollen mit Qt linken, mit der Version mit Threadunterstützung und wir hätten gerne Compilerwarnungen.
Das warn_on wird für den g++ zu einem -Wall.
Es gibt für die CONFIG noch eine Reihe andere Möglichkeiten, die alle in der Dokumentation zu qmake angeführt sind.
Das += wirkt dabei wie der C++ Operator +=, d.h. die neune Optione werden an eventuell zuvor gesetzte angefügt.
Dieser Operator kann auch bei SOURCES, HEADERS und INTERFACES benutzt werden.
Code:
SOURCES = lektion3.cpp qttutwidget.cpp
Diese Zeile gibt an, welche CPP Dateien zu unserem Projekt gehören.
Code:
HEADERS = qttutwidget.h
Diese Zeile gibt an, welche Header Dateien zu unserem Projekt gehören.
Das wird vorallem dann wichtig, wenn man eigene Signal/Slot Deklarationen hat.
Das gibt an, wie unser Endprodukt, in unserem Fall das Programm, heißen soll.
Um mit Hilfe dieser Datei und qmake ein Makefile erzeugen zu können, müssen wir in der Konsole einige Vorbereitungen treffen.
Zitat:
#> export QMAKESPEC=linux-g++
Das setzt die Umgebungsvariable QMAKESPEC, die qmake sagt, für welche Plattform und welchen Compiler das Makefile erzeugt werden soll.
Das ist bei Qt wichtig, da das selbe Programm auf verschiedenen Plattformen mit verschiedenen Compilern kompilierbar sein soll und das selbe auch für die Projektdatei gelten sollte.
Als nächstes überprüfen wir, ob die Umgebungsvariable QTDIR gesetzt ist:
Zitat:
#> echo $QTDIR
/usr/lib/qt-3.0.3
Ok, in unserem Fall ist alles in Ordnung.
Kommt kein Pfad, muss QTDIR erst gesetzt werden
Zitat:
#> export QTDIR=/usr/lib/qt-3.0.3
Bei Systemen wo die Headerdateien und Bibliotheken nicht unterhalb eines gemeinsamen Verzeichnis liegen, muss man einen kleinen Trick anwenden :)
Dieser Trick besteht darin, ein Pseudo Qt Verzeichnis anzulegen, dass dann symbolische Links zu den einzelnen Verzeichnisen enthält.
(Unter Debian haben das der Qt Packager schon gemacht. Diese Verzeichnis ist /usr/share/qt)
Das macht man entweder als root in einem systemweiten Verzeichnis oder als User in einem Verzeichnis wo man Schreibrechte hat.
Hier als Beispiel mit root Rechten
Zitat:
#> mkdir /usr/qtdir
#> cd /usr/qtdir
#> ln -s /usr/lib/qt lib
#> ln -s /usr/bin bin
#> ln -s /usr/include/qt3 include
Damit enthält unser qtdir Verzeichnis die erwarteten Unterverzeichnisse bin, include und lib.
Unsere Variable QTDIR setzen wir dann auf /usr/qtdir
Nach diesen Vorbereitungen können wir nun qmake starten
Zitat:
#> qmake -o Makefile lektion3.pro
Das sieht wie ein Compileraufruf aus und hat praktisch eine sehr ähnliche Funktion.
-o gibt an wie das Produkt heißen soll, danach kommt die Datei, die als Grundlage dient, also unsere Projektdatei.
Jetzt können wir unser Projekt wie zuvor mit den manuell erzeugten Makefiles erstellen lassen
qmake hat noch ein paar weitere Targets erzeugt, zum Beispiel clean.
Ein
löscht alle Dateien, die durch einen normalen make Aufruf erzeugt werden, also das ausführbare Programm und die Objectfiles.
Wird die Projektdatei geändert, erkennt das das alte Makefile über eine Regel, die die Projektdatei als Abhängigkeit hat, und erzeugt ein neues Makefile.
Lektion 5: Reagieren auf GUI Events
Autor: anda_skoa
In dieser Lektion werden wir sehen, wie man auf GUI Events, wie zB. Mausklicks, reagieren kann.
Als Basis nehmen wir die Dateien aus Lektion 4.
lektion5.pro ist absolut ident mit lektion3.pro, braucht also nur kopiert zu werden.
Für lektion5.cpp gilt das selbe, eventuell muss die Breite des Widgets vergößert werden.
qttutwidget.h und qttutwidget.cpp wurden nun folgendermaßen erweitert:
qttutwidget.h
Code:
#ifndef QTTUTWIDGET_H
#define QTTUTWIDGET_H
#include <qlabel.h>
class QtTutWidget : public QLabel
{
public:
QtTutWidget(QString text, QWidget* parent=0, const char* name=0);
protected:
void mousePressEvent(QMouseEvent* event);
void mouseReleaseEvent(QMouseEvent* event);
void mouseMoveEvent(QMouseEvent* event);
};
#endif
qttutwidget.cpp
Code:
#include "qttutwidget.h"
QtTutWidget::QtTutWidget(QString text, QWidget* parent, const char* name)
: QLabel(text, parent, name)
{
setPaletteBackgroundColor(Qt::black);
setPaletteForegroundColor(Qt::white);
setMouseTracking(true);
}
void QtTutWidget::mousePressEvent(QMouseEvent* event)
{
QColor color = paletteBackgroundColor();
int red = color.red();
int green = color.green();
int blue = color.blue();
switch (event->button())
{
case Qt::LeftButton:
red = 255;
break;
case Qt::MidButton:
green = 255;
break;
case Qt::RightButton:
blue = 255;
break;
default:
break;
}
color.setRgb(red, green, blue);
setPaletteBackgroundColor(color);
}
void QtTutWidget::mouseReleaseEvent(QMouseEvent* event)
{
QColor color = paletteBackgroundColor();
int red = color.red();
int green = color.green();
int blue = color.blue();
switch (event->button())
{
case Qt::LeftButton:
red = 0;
break;
case Qt::MidButton:
green = 0;
break;
case Qt::RightButton:
blue = 0;
break;
default:
break;
}
color.setRgb(red, green, blue);
setPaletteBackgroundColor(color);
}
void QtTutWidget::mouseMoveEvent(QMouseEvent* event)
{
QString posString;
posString.sprintf(" W:%d,%d / G:%d,%d ",
event->pos().x(), event->pos().y(),
event->globalPos().x(), event->globalPos().y());
setText(posString);
}
Das ist ja einiges an neuem Code, also wieder schön langsam der Reihe nach im Detail.
Code:
protected:
void mousePressEvent(QMouseEvent* event);
void mouseReleaseEvent(QMouseEvent* event);
void mouseMoveEvent(QMouseEvent* event);
In Qt werden die GUI Events an das jeweilige Widget zugestellt und dort in eine Eventhandler Methode verarbeitet.
Diese Methoden sind in der protected Sektion von QWidget deklariert.
Die Basisimplementation in der Klasse QWidget tut einfach nichts und auch QLabel, von dem wir ja ableiten, reagiert auf keine Mouse Events.
Wir müssen also die Methoden überschreiben, wenn dir etwas mit den Events machen wollen.
Hier überschreiben wir die Methoden für Drücken und Loslassen einer Maustaste und für Mausbewegungen.
Code:
setPaletteBackgroundColor(Qt::black);
setPaletteForegroundColor(Qt::white);
Wir setzen die Hintergrundfarbe unseres Widgets auf Schwarz und die Vordergrundfarbe auf Weiß.
Qt definiert im Namensraum Qt einige nützliche Konstanen, unter anderem auch Farbwerte.
Welche Farbwerte das sind, kann man in der Dokumentation von QColor nachlesen.
Code:
setMouseTracking(true);
Wir wollen über alle Mausbewegungen in unserem Widget informiert werden, auch wenn keine Taste gedrückt wird.
Darum aktivieren wir hier das Mouse-Tracking.
Code:
void QtTutWidget::mousePressEvent(QMouseEvent* event)
{
QColor color = paletteBackgroundColor();
int red = color.red();
int green = color.green();
int blue = color.blue();
Der Kopf einer unserer überschriebener Mouse Event Methode.
Zuerst holen wir uns die aktuelle Hintergrundfarbe.
Dann ermitteln wir die Werte der drei Grundfarben Rot, Grün und Blau (RGB Farbmodell).
Code:
switch (event->button())
{
case Qt::LeftButton:
red = 255;
break;
case Qt::MidButton:
green = 255;
break;
case Qt::RightButton:
blue = 255;
break;
default:
break;
}
Nun sehen wir über die Methode button() im QMouseEvent nach, welche Taste das Event ausgelöst hat.
Die im Namensraum Qt deklarierte Aufzählung ButtonState enthält vier Werte: LeftButton, MidButton, RightButton und NoButton.
Wir wollen auf Klicks reagieren also interessieren uns hier nur die drei "echten" Buttons.
Je nachdem welche Button zum Auslösen des Events geführt hat, ändern wir eine der drei Grundfarben auf ihr Maximum.
Code:
color.setRgb(red, green, blue);
setPaletteBackgroundColor(color);
Wir mischen nun die drei Gundfarben wieder zu einer Gesamtfarbe und setzen diese neue Farbe als unsere neue Hintergrundfarbe.
Die Methode mouseReleaseEvent macht praktisch genau das Gegenteil, wir gehen darum nicht näher daruf ein.
Code:
void QtTutWidget::mouseMoveEvent(QMouseEvent* event)
{
QString posString;
posString.sprintf(" W:%d,%d / G:%d,%d ",
event->pos().x(), event->pos().y(),
event->globalPos().x(), event->globalPos().y());
setText(posString);
}
In unserer Methode für Mausbewegungen wollen wir die Position des Mauszeiger in unserem Widget anzeigen lassen.
Bequemerweise kann unser Widget ja bereits einen Text anzeigen, weil es ja von QLabel abgeleitet ist.
Wir müssen also die Mauskoordinaten in einen QString umwandeln.
Dazu verwenden wir die Methode sprintf der Klasse QString.
Diese Methode verhält sich praktisch wie die gleichnamige Funktion aus der C Bibliothek, nur dass sie in einen QString statt in ein char Array schreibt.
Unser Formatstring zeigt an, dass wir vier Ganzzahlen ausgeben möchten.
Diese Zahlen sind die Position des Mauszeigers im Widget (nach W: ) und die Position des Mauszeigers in globalen Koordinaten (nach G: ).
Das QMouseEvent hat praktischerweise beide Positionen durch Methodenaufrufen verfügbar gemacht.
Der Rückgabewert beider Funktionen ist vom Typ QPoint.
Der so erzeugte QString wird mit der Methode setText, die unser Widget von QLabel geerbt hat, gesetzt.
Um Weiteres brauchen wir uns dann nicht mehr zu kümmern, dass erledigt unser QLabel Erbe :)
Erzeugung
Wie in Lektion 4 gezeigt wird mit Hilfe der .pro Datei ein Makefile generiert, dass uns dann mit make ein Programm erzeugt.
Lektion 7: Widgets mit Qt Designer
Autor: anda_skoa
In der vorigen Lektion habe wir unser Widget "händisch", also durch C++ Code, mit Unterwidgets ausgestattet.
Das ist natürlich bei größeren Widgets oder Dialogen mühsam und durch das fehlende visuelle Feedback nicht immer wie genwünscht hinzukriegen.
TrollTech bietet dafür den Designer an, ein Programm, mit dem man mit der Maus Widgets auf anderen Widgets plazieren und layouten kann.
Nach dem Start erscheint zuerst ein Dialog (template.png), der uns erlaubt, unser Widget basierend auf einer Vorlage zu erstellen.
Wir wählen einfach QWidget.
Nun ändern wir im Property Editor den Namen des Widgets auf QtTutWidgetBase (siehe properties.png).
Der Name wird dann zum Namen der generierten Klasse.
Ich wähle für Widgets, von denen ich dann ableite um sie mit Funktionn zu füllen, immer den eigentlichen Namen + Base.
Als Nächstest platzieren wird einen QLineEdit und einen QPushButton auf dem Widget (siehe elements.png).
Die verfügbaren Element sind links in einem Unterfenster des Designers, in verschiedenen Kategorien unterteilt, aufgelistet.
Das Auswählen erfolgt durch einfaches Klicken, das Platzieren durch Drücken und Ziehen der Maus.
Dann ändern wird im Property Editor die Namen der beiden Elemente. Diese Namen werden dann später die Variablennamen der beiden Elemente sein.
Wir haben hier m_button und m_lineEdit gewählt.
Anschliessend ändern wir den Text des Buttons. Das kann durch Doppelklick oder über den Property Editor erfolgen.
Die Widgets in Lektion 6 wurden durch ein QHBoxLayout verwaltet.
Das erreichen wird so:
zunächst wird unser Hauptwidget angeklickt. Zur Kontrolle sieht man am besten im Property Editor nach, ob dort die Eigenschaften des Widgets erscheinen.
Dann Klicken wir im Toolbar des Designer auf das Symbol für das horizontale Layout, drei vertikale Striche (siehen layout.png).
Dadurch wird unser Hauptwidget diesem Layout unterworfen. Man hat sofort ein visuelles Feedback, wie sich das auf die platzierten Komponenten auswirkt (siehe layouted.png)
Wir verkleinern nun unser Hauptwidget unter Kontrolle des Layouts, bis es eine angenehme Größe hat.
Der Designer erlaubt es, das erstellte Widget unter Anwendung verfügbarer WidgetStyles in einer Vorschau darzustellen.
Die erste Option im Menü Preview nimmt den aktuellen Style (siehe preview.png).
Die Vorschau ist aus funktionaler Natur: ein Button reagiert auf Klicks, der LineEdit zeigt einen blinkenden Cursor und erlaubt Texteingaben.
Jetzt speichern wir unsere Arbeit, am besten unter dem Namen des Widgets.
Das ist auch der Dateiname, den der Designer vorschlägt (siehe saving.png).
Intergration
Jetzt passen wir unsere übrigen Dateien an.
Zuerst die Projektdatei lektion7.pro
Code:
TEMPLATE = app
CONFIG += qt thread warn_on
SOURCES = lektion7.cpp qttutwidget.cpp
HEADERS = qttutwidget.h
FORMS = qttutwidgetbase.ui
TARGET = lektion7
MOC_DIR = mocs
OBJECTS_DIR = obj
UI_DIR = uics
Wir sehen zwei neue Zeilen.
Code:
FORMS = qttutwidgetbase.ui
Wie HEADERS und SOURCES gibt FORMS eine Liste von Dateien an, in Falle von FORMS eben Dateien des Designer.
Diese Zeile gibt an, in welches Unerverzeichnis die Dateien kommen, die UIC, der User Inferface Compiler, aus den .ui Datein generiert.
Diese Dateien sind normale Header und Quelldateien, sollten aber nicht geändert werden, weil bei einem erneuten UIC Lauf alle Änderungen wieder überschrieben werden.
Um sie von unserern "echten" Dateien zu trennen, verbannen wir sie mit der UI_DIR Zeile eben ins Interverzeichnis uics.
lektion7.cpp ist identisch mit lektion6.cpp
qttutwidget.h
Code:
#ifndef QTTUTWIDGET_H
#define QTTUTWIDGET_H
// local includes
#include "qttutwidgetbase.h"
class QLineEdit;
class QtTutWidget : public QtTutWidgetBase
{
Q_OBJECT
public:
QtTutWidget(QWidget* parent=0, const char* name=0);
protected slots:
void slotButtonClicked();
};
#endif
Als include brauchen wir nun den generierten Header. Der Name wird aus dem Namen der .ui Datei generiert und heißt darum bei uns qttutwidgetbase.h
Die Basisklasse unserer QtTutWidgets ist nun auch statt QWidget QtTutWidgetBase. Das hier ist der Name, den wir dem Widget im Property Editor gegeben haben.
Weiters ist die Sektion mit der QLineEdit Variable hinfällig geworden.
qttutwidget.cpp
Code:
#include <qpushbutton.h>
#include <qlineedit.h>
#include <qmessagebox.h>
#include "qttutwidget.h"
QtTutWidget::QtTutWidget(QWidget* parent, const char* name)
: QtTutWidgetBase(parent, name)
{
QObject::connect(m_button, SIGNAL(clicked()), this, SLOT(slotButtonClicked()));
}
void QtTutWidget::slotButtonClicked()
{
QString text = m_lineEdit->text();
if (text.stripWhiteSpace().isEmpty()) return;
QMessageBox::information(this, "Wichtig", text);
}
Im Konstruktor wurde auch hier QWidget durch QtTutWidgetBase ersetzt. Der Funktionskörper ist nun viel kürzer, weil ja wir ja weder Layout noch Element anlegen müssen.
Die Variable des Buttons heißt nun m_button (meine Schreibweise für Membervariablen), darum ändert sich der connect Aufruf ebenfalls.
Die Slot Implementation ist völlig identisch, da wir als Namen für die LineEdit Variable wieder m_lineEdit gewählt haben.
