GUI-Toolkit und andere Entscheidungen
-
Hallo,
ich programmiere schon seit längerem Konsolenanwendungen in C++ (hauptsächlich über Textpad oder VS05 und GCC) und möchte mich nun in die Welt der grafischen Oberfläche stürzen. Bisher bin ich ein bekennender Windows-Nutzer, würde aber auch gerne für (und vielleicht sogar mit???) Linux programmieren, da Windows mit jeder Inkarnation weniger attraktiv wird.Natürlich habe ich zu diesem Thema schon Google befragt (so bin ich auch auf dieses Forum gestoßen) und hier etwas rumgelesen (insbesondere die FAQ, sowie hier, hier, hier und hier).
In die engere Wahl habe ich nun QT und wxWidgets genommen, kann mich aber noch nicht so ganz entscheiden. Hier ist worauf ich besonderen Wert lege (ausser der Plattformunabhängigkeit):
- möglichst hohe Performance! (x32/x64, mehrere Threads)
- gute Lektüre/Support (ich schätze das QT hier die Nase vorn hat, da ich schon mehrere Bücher über QT gesehen habe)
- IDE (ich mag eigentlich die VS-IDE wegen der Vervollständigung, aber vielleicht ist eine andere ja besser geeignet).Sorgen mache ich mir vor allem um die Performance, da ich ein Optimierungs-Freak bin. Ich bin zwar noch kein guter Programmierer, würde aber gerne mal einer werden (und mein Programm nicht aus vorgefertigten Templates zusammenbasteln die tausend Zeilen Code mitbringen die man gar nicht benötigt).
Was würdet ihr empfehlen? QT, wxWidgets oder doch erstmal die WinAPI zum Einstieg?
Vielen Dank schonmal für eure Meinungen!
-
Die Vor und Nachteile von Qt und wxWidgets hast du dir ja schon in anderen Threads angeschaut,
daher gehe ich da jetzt mal nicht drauf ein...Wichtig ist eigentlich nur, das du die OOP und C++ gut beherrschst.
wxWidgets lässt sich recht gut mit anderen Libraries kombinieren, z.b. Boost.
Die Performance dürfte daher von beiden Toolkits gleich sein, und hängt eher
vom Programmierer bzw. der gewählten Implementation ab.
GUI ist aber generell nicht immer Performant, so das man evtl. rechen intensive
Aufgaben in einen eigenen Thread /Prozess auslagern sollte. Kommt natürlich
auch davon ab, wie performant eine Anwendung sein muss.phlox
-
Also die GUI hat doch nichts mit der Programmperformance zu tun. Klar kann die GUI selbst langsam implementiert sein. Das ist aber bei keiner der Major-Libraries der Fall. Was machst du denn in einer GUI? Die GUI wartet meistens auf User-Eingaben. Was willst du beim Warten an Performance rausholen? *kopfschüttel* Und wenn du lange Berechnungen durchführst (sagen wir mal Apfelmännchen berechnen) lagert man das eh in einen separaten Thread aus, damit die GUI nicht blockiert wird (Blockade hat aber auch nichts mit Performance zu tun, ist nur eine konzeptionelle Sache).
Die Entscheidung ob Qt oder wx hängt meiner Meinung nach von zwei oder vielleicht drei Faktoren ab (weil das die essentiellen Unterschiede sind!):
1. Die Lizenz! Schau dir die Lizenzen und evtl. die aufkommenden Kosten an!
2. Schau dir den C++-Style an, wenn dir C++-Style wichtig ist.
(3. Evtl. ist dir 100% natives Look&Feel wichtig?)Wobei ich 1. Punkt für den alles entscheidenden halte, vorallem für Hobby-/Amateur-Entwickler!
-
phlox81 schrieb:
Die Vor und Nachteile von Qt und wxWidgets hast du dir ja schon in anderen Threads angeschaut,
daher gehe ich da jetzt mal nicht drauf ein...Wichtig ist eigentlich nur, das du die OOP und C++ gut beherrschst.
wxWidgets lässt sich recht gut mit anderen Libraries kombinieren, z.b. Boost.
Die Performance dürfte daher von beiden Toolkits gleich sein, und hängt eher
vom Programmierer bzw. der gewählten Implementation ab.I see. Danke.
GUI ist aber generell nicht immer Performant, so das man evtl. rechen intensive
Aufgaben in einen eigenen Thread /Prozess auslagern sollte. Kommt natürlich
auch davon ab, wie performant eine Anwendung sein muss.Im Moment mache ich viel mit neuronalen Netzen, da ist klar das die eigene Threads bekommen.
Edit: Wichtig dabei wäre mir aber z.B. das die Werte/Grafiken reibungslos auf der Oberfläche aktualisiert werden und man keine hässlichen Aussetzer hat (ich sehe ein das dies sicherlich auch eine Frage des Programmierens ist).Artchi schrieb:
Also die GUI hat doch nichts mit der Programmperformance zu tun. Klar kann die GUI selbst langsam implementiert sein. Das ist aber bei keiner der Major-Libraries der Fall.
Gut zu wissen. Da ich keine Ahnung von GUIs Toolkits habe, war ich mir da nicht so sicher. Ich habe nur an Java und dessen Performanceprobleme gedacht (ja, ich bin mir sehr wohl bewusst das das völlig andere Gründe hat) und befürchtet, ähnliches könnte bei "schlechteren" Toolkits auch der Fall sein, wie z.B. auch Windowblinds zeigt. Obwohl es das Programm schon recht lange gibt und angeblich nicht nur stabil sondern auch noch schneller als die Implementation von Windows sein soll (bei vergleichbaren Skins), bin ich von dem Ergebnis absolut nicht überzeugt (weder von der Geschwindigkeit noch der Stabilität).
Was machst du denn in einer GUI? Die GUI wartet meistens auf User-Eingaben. Was willst du beim Warten an Performance rausholen? *kopfschüttel*
Ja, genau. Und solche "einfachen" Aufgaben sollen möglichst wenig Ressourcen fressen.
Und wenn du lange Berechnungen durchführst (sagen wir mal Apfelmännchen berechnen) lagert man das eh in einen separaten Thread aus, damit die GUI nicht blockiert wird (Blockade hat aber auch nichts mit Performance zu tun, ist nur eine konzeptionelle Sache).
Ja, wie gesagt, das ist klar. Dennoch wäre es ja interessant zu wissen wie sich die Applikation verhält wenn mehrere Unterfenster mit vielen Buttons offen sind und die Fenster bewegt werden. Wie gesagt, ich habe noch keine rechte Vorstellung davon, wie das alles implementiert ist. Aber nach euren Aussagen gehe ich mal einfach davon aus das Performance keine Rollen spielt.
Die Entscheidung ob Qt oder wx hängt meiner Meinung nach von zwei oder vielleicht drei Faktoren ab (weil das die essentiellen Unterschiede sind!):
1. Die Lizenz! Schau dir die Lizenzen und evtl. die aufkommenden Kosten an!
2. Schau dir den C++-Style an, wenn dir C++-Style wichtig ist.
(3. Evtl. ist dir 100% natives Look&Feel wichtig?)Wobei ich 1. Punkt für den alles entscheidenden halte, vorallem für Hobby-/Amateur-Entwickler!
Punkt 1 ist klar. Wie an anderer Stelle im Forum erläutert lässt einem die GPL ja bei beiden recht große Freiräume (ich gehe mal davon aus das man bei der frei erhältlichen Version von QT denselben Funktionumfang bekommt). Punkt 2 verstehe ich ehrlich gesagt nicht so ganz was du meinst.
Und Punkt 3 ist ehrlich gesagt schon recht wichtig. Bei diesen Java-Fenstern läuft mir immer ein kalter Schauer über den Rücken, auch wenn es ganz nett zu programmieren ist. Aber die Screenshot von QT und wxWidgets sehen ja ganz gut aus. Worauf sollte man denn da achten. Hast du da ein paar Beispiele die den Unterschied erläutern?
-
wxWidget benutzt Systemwidget und QT zeichent seine Widget selbst.
-
Gut zu wissen. Da ich keine Ahnung von GUIs Toolkits habe, war ich mir da nicht so sicher. Ich habe nur an Java und dessen Performanceprobleme gedacht (ja, ich bin mir sehr wohl bewusst das das völlig andere Gründe hat) und befürchtet, ähnliches könnte bei "schlechteren" Toolkits auch der Fall sein, wie z.B. auch Windowblinds zeigt. Obwohl es das Programm schon recht lange gibt und angeblich nicht nur stabil sondern auch noch schneller als die Implementation von Windows sein soll (bei vergleichbaren Skins), bin ich von dem Ergebnis absolut nicht überzeugt (weder von der Geschwindigkeit noch der Stabilität).
Also WindowBlinds ist aber noch mal was ganz anderes. Das Ding sitzt doch architektonisch ganz woanders. Streich das mal für deine Toolkitsuche aus dem Kopf.
Java zeichnet seine GUI selber, bis auf den Fensterrahmen. Das macht Qt auch so, wobei man bei Qt tatsächlich mehr Performance verspüren kann. Deshalb gibt es seit kurzem auch Qt für Java.
wxWidgets und VCF wiederrum zeichnen ihre GUI nicht selbst, sondern nutzen die Win32-Betriebssystem-Komponenten. D.h. hier ist immer Windows für die Performance zuständig.
Ja, genau. Und solche "einfachen" Aufgaben sollen möglichst wenig Ressourcen fressen.
Kenne kein Toolkit, das beim Warten Resourcen frisst.
Ja, wie gesagt, das ist klar. Dennoch wäre es ja interessant zu wissen wie sich die Applikation verhält wenn mehrere Unterfenster mit vielen Buttons offen sind und die Fenster bewegt werden.
Siehe meine obigen Ausführungen bzgl. "selber zeichnen". Beim selber Zeichnen von vielen Buttons, Unterfenstern usw. gibt wx und VCF die Verantwortung an das OS ab. Qt machts selber, aber besser als Javas Swing.
Punkt 1 ist klar. Wie an anderer Stelle im Forum erläutert lässt einem die GPL ja bei beiden recht große Freiräume (ich gehe mal davon aus das man bei der frei erhältlichen Version von QT denselben Funktionumfang bekommt).
Naja, ob die GPL Freiräume anbietet, ist Ansichtssache.
Aber vom Funktionsumfang sind die GPL- und Kommerz-Variante von Qt gleich.Punkt 2 verstehe ich ehrlich gesagt nicht so ganz was du meinst.
Dann ist es dir wahrscheinlich auch egal. :p
Und Punkt 3 ist ehrlich gesagt schon recht wichtig. Bei diesen Java-Fenstern läuft mir immer ein kalter Schauer über den Rücken, auch wenn es ganz nett zu programmieren ist. Aber die Screenshot von QT und wxWidgets sehen ja ganz gut aus. Worauf sollte man denn da achten. Hast du da ein paar Beispiele die den Unterschied erläutern?
Naja, wx und VCF benutzt halt immer Win32-Controls. D.h. der Benutzer hat dann unter Vista autom. auch ein Vista Look & Feel. Qt hat dagegen das Problem wie Swing: alles muß nachprogrammiert werden. Natürlich versucht Qt sogut wie möglich an das orig. ran zu kommen. Entscheidend ist, ob einem das letzte kleinste Detail des Look&Feels wichtig ist? Hängt vom Kunden ab oder vom eigenen Geschmack. Ich will Qt nicht schlecht machen. Qt ist ne ernsthafte Library die professionell eingesetzt wird. Trotzdem muß es deshalb nicht mit der eigenen Anforderung konform gehen. Mußt du selber entscheiden.
Ein Tip: du wirst eh wx und qt mal ausprobieren zu müssen. (Downloaden, Einrichten, Helloworld erstellen, compilieren, ausführen) DANN kann man erst sagen, was man nimmt. Weil schon alleine das Einrichten unter VC++2005 bei beiden ein himmel weiter Unterschied ist.
-
Obwohl das selbstzeichen machmal ein auch kleiner Vorteil hat, wenn man sein eigenes Look and Feel haben möchte.
Siehe Avalon, die Trennung von Design und Funktionalität stand im Vordergrund, so dass man ein Eigenes LaF entwicklen kann von Designer nicht vom Programmier!
-
[quote="Artchi"]
Naja, wx und VCF benutzt halt immer Win32-Controls. D.h. der Benutzer hat dann unter Vista autom. auch ein Vista Look & Feel. Qt hat dagegen das Problem wie Swing: alles muß nachprogrammiert werden. Natürlich versucht Qt sogut wie möglich an das orig. ran zu kommen. Entscheidend ist, ob einem das letzte kleinste Detail des Look&Feels wichtig ist? Hängt vom Kunden ab oder vom eigenen Geschmack. Ich will Qt nicht schlecht machen. Qt ist ne ernsthafte Library die professionell eingesetzt wird. Trotzdem muß es deshalb nicht mit der eigenen Anforderung konform gehen. Mußt du selber entscheiden.
Hmmm, ich habe Qt nie benutzt, aber ich meine mich zu erinnern, das ich damals, als die Toolkit-Entscheidung für mich anstand gelesen zu haben, dass Qt ein Theme hat, bei dem es die Controls über die UXTheme.dll zeichnet.
Wenn das stimmt, sehen die Qt-Controls auch immer Nativ aus, egal ob der User ein eigenen Visual Style installiert hat oder auf Vista umsteigt.
Ich habe in wxWidgets auch diverse Controls selbstgezeichnet (z.B. als simpelstes Beispiel den Push-Button, weil wx keinen Button mit Icon und Text anbietet). Da ich ebenfalls die UXTheme.dll verwende, sehen meine Buttons trotzdem immer genauso aus, wie die nativen Buttons, selbst unter Vista.
Ich gehe mal davon aus, dass es bei Qt dasselbe ist. Selbst Java berücksichtigt meinen Visual Style und zeichnet nicht stumpf die XP-Controls nach (zumindest im TV-Browser, das einzige Java-Programm das ich verwende).
Edit: Okay, mir ist gerade eingefallen, dass ich noch ein Java-Programm habe: Die DB2-GUI-Tools von IBM. Da muss ich meine Aussage doch wieder etwas revidieren. Java berücksichtigt zwar Teilweise meinen Visual Style (z.B. für Buttons, Tree-List, eingestellte Hintergrund-Farbe), bei anderen Sachen aber überhaupt nicht. Das List-Control sieht z.B. noch schlechter aus als zur Win95-Steinzeit.
-
@Zeus! Du meinst wohl eher ein eigenes Look? Ein anderes Feel wollen eigentlich die wenigsten. Ja, das selbst Zeichnen kann ein neues Look vereinfachen. Aber auch native Controls kann man selbst übermalen... ganz legal. Wie gesagt, ist eine Entscheidung die man dem Fragesteller dieses Threads nicht abnehmen kann. Ich pers. bevorzuge für "ernsthafte" Anwendungen das orig. Look&Feel. Wenn ich eine Multimedia-Software entwickel, benutze ich eher was anderes als Swing, Qt oder wx. Da würde ich eher eine 3D-Engine für die GUI benutzen.
-
@Frenki! Ehem, sorry, aber wie in meinem Posting gesagt: Ist einem das letzte Detail wichtig? Und ehrlich? Das kann Qt und Swing nicht leisten! Auch wenn diese einen "Trick" anwenden und im Background etwas zeichnen und es in das sichtbare Fenster "projezieren". Der Witz ist aber, das du zwar eine Kopie vom orig. Control hast, dir aber immer noch das Feel fehlt. Wo ist denn unter Swing, Qt und GTK(mm) das bekannte Rechte-Maustaste-Menü aus meinem Windows in Textfeldern? Wo sind denn die Fade-Animationen von Defaultbuttons oder Progressbalken die ich bei WindowBlinds oder Vista normalerweise habe? Es sind einfach nur Notlösungen. Klar hast du mit den selbstzeichnenden Toolkits schon eine gute Annäherung, aber die Details sind einfach nicht vorhanden. Manchmal ganz essenzielle Details, die ich von Windows-Controls kenne.
Wem diese Details nicht wichtig sind, wird mit selbstzeichnenden GUIs zufrieden sein. Aber man sollte diese auch nicht verheimlichen, wenn jemand hier eine Beratung sucht.
-
Du hast natürlich recht, einhundertprozentig kriegt man es nie nachgebaut.
Mir persönlich reicht es aber, wenn der User sich sofort Zuhause fühlt, und nicht einen Look hat, der seine Einstellungen völlig ignoriert.
Muss natürlich jeder selbst wissen ob ihm die 99 Prozentige annährung reicht. Ich persönlich würde meine Entscheidung für ein Toolkit jedenfalls nicht daran aufhängen, da gibt es wirklich wichtigeres.
-
Danke für eure ausführlichen Antworten und die Mühe, die ihr euch gemacht habt.
Ich denke ich werde es erstmal mit wxWidgets anschauen und mal probieren wie es läuft.
Und da man ja auch bei wxWidgets die Fenster anpassen können soll, werde ich mal schaun wieweit ich damit komme (dauert wohl eh' noch ein bisschen).
Also wie gesagt - vielen Dank soweit!
-
Dann schau dir einfach mal das wxWidgets Tutorial im Magazin an.
Nächste Woche erscheint (wahrscheinlich) Teil 2.
-
Ich habe das Thema
http://www.c-plusplus.net/forum/viewtopic-var-t-is-175103.html
in diesem Forum gelesen.Die Themen sind verwandt. In meinem Fall geht's wohl um eine getroffene Entscheidung: wxWidgets und GTK. Hat jemand eine Idee, was ich versuchen könnte?
Problembeschreibung
Ich entwickle ein graphisches Bedienfeld für eine Gerätefamilie basierend auf dem Toradex Colibri 520 (PXA270) Modul.
Das System soll unter Linux laufen. Die Geräte sind über CAN Bus - realisiert mit SJA1000 am Datenbus des Moduls – an das Colibri angeschlossen. Die Anzeige der Signale und die Bedienung der Geräte erfolgt mittels eines Touch Screens.
Dabei sind einige Software Probleme aufgetretten.
Die Reaktionszeit der Bedienoberfläche ist extrem lang. Genau gesagt, viele Funktionen der GTK+ laufen sehr langsam. Z.B. 70 ms pro Erstellen einer Eingabebox! Beim Erstellen eines kompletten Dialogs (mit 50 Eingabeboxen) kämen dann bis 10-12 s zusammen.
Eine andere langsame Funktion ist das Ändern der Beschriftung (Texte) der Tasten. Das dauert auch um die 70 ms pro Taste. Bei 10 Tasten wird’s schon um eine Sekunde.
Die Bedienoberfläche ist relativ einfach. Es geht um eine grafische Anzeige der Sensorsignale und ca 10 verschiedene Dialogboxen mit je 20-50 Eingabefeldern. Es kann max 1 Dialog zur Eingabe aktiviert werden. Es gibt keine Animationen, Datenbänke o.ä.
Konfiguration
Kernel Basis:
linux-2.4.29-vrs1—col2 wie es aus der Toradex Internet Seite kommt.
Kernel Anpassungen:
Treiber für CAN SJA1000T von Can4Linux an die Hardware angepasst.
Glibc
2.3.2 pxa27x mit Ihrem Patch von Toradex Download Seite angepasst.
Gcc
3.4.3 pxa-r1 mit Ihrem Patch von Toradex Download Seite angepasst.
X-Server:
Xfbdev über OE CVS 2006.03.12-r11 läuft auf dem fbdev. Fbdev ist mit 16 Bits 640x400.
X11, libX:
verschiedene X Bibliotheke X11R7.1 von September 2006
Glib 2:
2.12.1 über OE September 2006
GTK+
2.10.2 mit pango(1.14.0) + cairo(1.2.4) über OE
wxWidgets
2.6.3 über OE September 2006Die Bediensoftware (mit wxWidgets) habe ich auch für Windows und für Linux-x86 kompiliert. Sie läuft anwandfrei an 4 Jahre alten Rechnern mit 600 MHz Intel CPUs. Ich habe auch eine Windows CE Testapplikation für Colibri geschrieben. Dort lassen sich die Eingabefelder auch anwandfrei bedienen.
Ich habe mehrere Tests durchgeführt
1. X-Server an einem anderen Linux-Rechner. In diesem Fall lief die Aufbau der Dialoge NICHT schneller, als wenn der X-Server am gleichen Colibri Rechner laufen würde.
2. Kernel 2.6 statt 2.4. Kernel 2.6 hat leider mehrere notwendige Treiber nicht mehr. Z.B. die Unterstützung vom Touch Screen über UCB1400, Ändern der CPU Frequenz über die „proc“ Kernelinterface. Die Aufbau der Dialoge war aber gleich langsam.
3. Ich habe den FrameBuffer von 8 Bit (mit Palette) auf 16 Bit (ohne Palette) umgestellt. So spart man den Aufwand der Palette. Das hat eine deutliche Verbesserung beim Zeigen und Verstecken der Fenster gebracht. Die Aufbau der neuen Dialoge ist leider gleich langsam geblieben.
Welche Gründe könnte es für die extrem langsame Funktion des Linux Systems mit X-Server, GTK+ und wxWidgets geben?
Wäre es sinnvoll einen Versuch mit Qt-X oder Qt-Embedded durchzuführen?
Über einige Tips würde ich mich sehr freuen.