Hallo zusammen!
Ich bin gerade dabei einen kleinen Roboter zu bauen, der mit einem
mini-ITX-Board (Linux) und einer USB-Webcam ausgestattet ist, um etwas
Bildverarbeitung "zu üben" (mit ITK und C++).
In der Entwicklungsphase möchte ich in Echtzeit verschieden gefilterte
Bilder von den Webcams und erkannte Objekte mit einem Monitor betrachten
(evtl. remote über WLAN-Verbindung) und dazu eine kleine Anwendung
schreiben.
Frage: Sollte ich die Anwendung eher mit dem GTKmm+ oder dem QT-Toolkit
entwickeln? Überall im Internet liest man nur: Geschmackssache!
Was meint ihr?
(PS: Habe bisher nur n bisschen Windows-MFC programmiert und keine
Erfahrung mit dem X-Server, muss mich also auf jeden Fall erst
einarbeiten.)
An der Geschmackssache ist schon etwas dran: Für beide Toolkits gibt
es sowohl viele User (Gnome- bzw. KDE-User) als auch viele
Applikationen und damit Entwickler. So schlecht können also beide
nicht sein,
Ich selbst verwende hin und wieder GTKmm und bin zufrieden damit. Ich
kenne Qt allerdings nur oberflächlich und kann deswegen keine relative
Bewertung abgeben. Im Vergleich zur MFC sind aber beide allererste
Sahne. Die Entwicklung der MFC ist halt vor 10+ Jahren stehen
geblieben, d.h. zu einer Zeit, wo die Entwicklung von Qt und GTK erst
begann.
Ich stand vor einiger Zeit vor demselben Problem wie du und habe Qt,
GTK+ und GTKmm in engere Auswahl gezogen. Da die Entscheidung
zeitkritisch war, habe ich keines der drei einer intensiven
Untersuchung unterzogen. Die (sehr mageren) Entscheidungskriterien
waren für mich schließlich:
- Qt definiert für das Signal-/Slot-Handling (d.h. die Verknüpfung von
Wigdets mit den zugehörigen C++-Methodenaufrufen) eine
Spracherweiterung von C++, weswegen der Programmcode erst durch
einen Präcompiler geschickt werden muss. Das ist zwar nicht weiter
tragisch und die Erweiterungen verunstalten den C++-Code kaum, aber
ich wollte, wenn schon C++, richtiges C++ programmieren. Aber das
ist eine Philosophiefrage.
- GTK+ hat ein reines C-API, das natürlich auch in C++-Prgrammen
verwendet werden kann. Allerdings wird - vor allem bei den
Callback-Aufrufen - sprachbedingt sehr viel mit void-Pointern
herumgeschmissen, was gerade beim Einstieg die Gefahr von schwer
debugbaren Programmcrashes mit sich bringt. Und GUI-Toolkits sind ja
eines der Paradebeispiele für den Einsatz objektorientierter
Programmierung.
- GTKmm ist ein Wrapper um GTK+. Er ist m.E. sehr gut gelungen, und
man merkt praktisch nicht, das er nur aufgesetzt ist. Man könnte
annehmen, dass unter diesem zweischichtigen Aufbau die Effizienz
leidet, allerdings ist mir noch nie aufgefallen, dass GTKmm-
Programme (auch von anderen) schlechter laufen als GTK+-Programme.
Das Signal-/Slot-Handling wird mit libsigc++ gemacht, das 100%
typsichere Callbacks ermöglicht. libsigc++ benötigt keine Sprach-
erweiterungen aus, sondern ist sehr elegant mit C++-Templates
realisiert.
Schließlich bin ich dann bei GTKmm hängengeblieben. Die Lizenz von
GTK+/GTKmm ist LGPL, so dass man diese Bibliotheken problem- und
kostenlos auch für kommerzielle Projekte einsetzen kann. Bei der Qt
muss man in bestimmten Fällen etwas Geld rüberschieben.
Sowohl Qt als auch GTKmm lassen sich auch unter Windows einsetzen, so
dass man leicht portable GUI-Programme schreiben kann. Mit GTKmm habe
ich das schon gemacht (MinGW und MTools als Programmiertools für
Windows). Den Quellcode des Programms konnte ich unverändert
übernehmen, im Makefile habe ich ein paar kleine Änderungen
vorgenommen.
Erst mal vielen Dank für die ausführliche Antwort!
Anscheinend gibt es wirklich keine rein objektive Antwort auf diese
Frage... Dann werde ich das davon abhängig machen, welche IDE mir am
besten gefällt und welche visuellen Entwicklungswerkzeuge es dafür gibt.
Denn ich habe keine Lust die Benutzer-Oberfläche "manuell" zu erstellen.
Ich möchte mich eher auf die Bildverarbeitungs-Algorithmen
konzentrieren...
Gruß, Andy
Hallo,
QT hat ein grosses vorteil, wenn du etwas mit netwerk anfangen willst,
gibt es schon alle notige komponenten in bibliotek drin, auserdem sehr
gute OpenGL anbindung, XML und eigene STL implementation. Die programmen
damit schreiben ist kinderleicht. VS Studio Integration, und andere
werkzeuge (z.B. QDevelop, QLinguist u.s.w.)
eine gute IDE dafür ist KDevelop (www.kdevelop.org)
MfG
Yuri
Qt ist die umfangreichere Lösung. Es gibt, soweit ich das bisher gesehen
haben, deutlich mehr Widgets als unter Qt. Man bekommt sogar Support für
SQL Datenbanken und sowas.
Außerdem kann man mit dem Qt Designer die Oberflächen für meinen
Geschmack deutlich einfacher erstellen. Mit GTK komme ich nicht zurecht.
Bei Qt hat man einfach einfach sein Fenster und platziert da per
drag&drop die Elemente und macht sie so groß oder klein wie man will.
Bei GTK muss man mit Packing Widgets erstmal das Fenster wie eine
Tabelle unterteilen. Damit komme ich irgendwie nicht zurecht
> Bei Qt hat man einfach einfach sein Fenster und platziert da per> drag&drop die Elemente und macht sie so groß oder klein wie man will.> Bei GTK muss man mit Packing Widgets erstmal das Fenster wie eine> Tabelle unterteilen. Damit komme ich irgendwie nicht zurecht
Dafür gibt's bei Qt Layouts. Die Idee ist, daß die Widgets sich samt
Inhalt an die Größe des parent-Widgets anpassen, damit man nicht im
Programm die Großen fest vorgeben muß. Nichts ist nerviger als ein zu
kleines Fenster, das man nicht größer ziehen kann, weil das
Fensterlayout fest vorgegeben ist.
Noch was anders: Wenn man mit Qt Graphen darstellen will, bietet sich
noch Qwt ( http://qwt.sf.net/ ) an. Das ist eine auf Qt aufsetzende
Widget-Bibliohtek, mit der man optisch ansprechende Graphen in sein
Programm einbauen kann.
> Bei Qt hat man einfach einfach sein Fenster und platziert da per> drag&drop die Elemente und macht sie so groß oder klein wie man> will.
Gibt's bei GTK auch. Innerhalb eines Fixed-Containers werden alle
Widgets fest platziert. Das wird auch vom grafischen UI-Editor Glade
unterstützt.
> Bei GTK muss man mit Packing Widgets erstmal das Fenster wie eine> Tabelle unterteilen. Damit komme ich irgendwie nicht zurecht
Man darf. Und will, meistens zumindest ;-)
Die Zeiten der starren GUIs, wie sie vom MS-Dialogeditor für MFC
generiert wurden, sind längst vorbei. Damals, als jeder eine VGA-Karte
mit der einheitlichen Auflösung von 640x480 hatte, war das ok.
Heute will man, dass beim Vergrößern eines Fensters auf 1920x1200 oder
noch größer Größe und Anordnung der einzelnen Widgets sinnvoll
mitskaliert werden. Bspw. soll eine Zeichenfläche mitvergrößert
werden, während Buttens am Rand des Fensters ihre Größe beibehalten.
Der Button in der rechten unteren Ecke soll aber dort bleiben, d.h. er
muss seine Koordinaten ändern. Ein Feld für eine Statusausgabe unter
der Zeichenfläche soll vielleicht ebenfalls mitvergrößert werden, aber
nur in vertikaler Richtung und nur bis zu einer Maximalgröße von 10
Textzeilen, usw. usw.
Genau dieses wird durch die automatischen Layouter, die jede etwas
modernere GUI-Bibliothek (natürlich auch Qt, s. Post von Magnus)
mitbringt, bewerkstelligt. Das funktioniert so genial, dass ich den
grafischen UI-Editor für GTK nur selten benutze, obwohl dieser schon
sehr gut gemacht ist.
Vor allem sind automatisch gepackte GUIs viel leichter wartbar, da
bspw. ein Button leicht nachträglich in einen Dialog hineingequetscht
werden kann, ohne die restlichen Widgets manuell neuplatzieren zu
müssen.
Ich weiß. Aber Widgets mit veränderbaren Größen sind auch mit Qt kein
Problem. Aber egal, mal ganz davon abgesehen wie man die Oberfläche
zusammenbaut, ich finde Qt insgesamt etwas besser, vor allem seit es
eine GPL Lizenz gibt :)
Eingangs wurde MFC angesprochen - für Umsteiger ist dann wxWidgets
geeignet, das ist der MFC einerseits überlegen, andererseits ist aber
kein vollständiges Umdenken erforderlich.
