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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.