GUI Programmierung: Toolkit vergleich

[pinky]

Hallo,
ich weiß das diese Thema absolutes flame Potential hat. Trotzdem will ich mal den Versuch machen es einigermaßen objektiv zu diskutieren, so wie ich das Forum hier kennen geklernt habe denke ich das es durchaus möglich sein könnte.

Also ich beginne einfach mal mit meiner Meinung/Erfahrung und hoffe dann auf rege Beitligung:

Lange Zeit gehört ich zu denjenigen die in Qt das technisch beste Toolkit sahen:
- C++ (sicher eine gut geeignete Sprache für GUI sachen und sehr weit verbreitet)
- Qt macht es wirklich einfach, auch an Stellen wo C++ selber etwas "komplizierter" ist.

Mittlerweile sehe ich Qt etwas anders. Wenn man mit Qt programmiert hat man sehr schnell einen Quellcode voller QString, Qfoo, Qbar,... Sachen. Ok, als man mit Qt anfing gab es noch keinen namespace, ich denke langsam wäre es aber mal an der Zeit etwas aufzuräumen und die Qt Sachen sauber in ihren eigenen namespace zu packen (Qt::String usw).
Ausserdem fällt immer stärker auf, dass Qt an vielen Stellen das Rad neu erfindet anstatt auf bewährte C++ und STL Sachen zurück zu greifen. Es mag sein, dass es an der einen oder anderen Stelle sinnvoll ist und die Programmierung vereinfacht (siehe auch meine Vorteile von Qt), aber auf der anderen Seite entwickelt man sich damit immer weiter Weg von C++ und kann bei Qt fast schon von einer "eigenen" Programmiersprache auf der Basis von C++ sprechen. Dadurch wird auch das bewährte Konzept verhindert oder zumindest gestört Daten und GUI zu trennen, da die Versuchung groß ist auch bei den Daten Klassen eine bequeme Qirgendwas Klasse zu verwenden als Standard C++, wodurch die Programme sehr stark auf Qt festlegelt sind und eine Portierung nur noch sehr schwer bis unmöglich ist.
Dazu kommt, dass es einen in meinen Augen zu sehr verwöhnt, als ich eine Zeit lang Qt-GUI Programme geschrieben habe, hatte ich echt Probleme wieder in "normales" C++ rein zu kommen, da ich es gewohnt war die ganzen QIrgendwas Klassen zu verwenden.

Auf der anderen Seite der großen Toolkits steht Gtk+, was ich für technisch eher schlecht gehalten habe, da eben in C geschrieben. Mittlerweile sehe ich das etwas anderes.
Die Basis in C zu schreiben hat durchaus seine Vorteile, da C wahrscheinlich die Sprache ist die am einfachsten und besten auf allen Systemen läuft (u.a. auch wegen dem kleinen Sprachumfang) und man von C ausgehend sehr einfach verschiedene Sprachbindings entwickeln kann, so ist niemand gezwungen heute GUI Anwendungen in C zu schreiben. Diese hohe Flexibilität erlaubt es immer mit der Zeit zu gehen, egal ob es die C++ Bindings, "exotischere" Sprachen wie lisp, scheme, perl, python, php,... waren, oder wie aktuell mit Mono gezeigt die schnelle anbindung an neue Technologien mit gtk#. Wodurch eigentlich jeder, egal welche Sprache oder Technologie er bevorzugt mit Gtk einfach GUI Anwendungen schreiben kann und gleichzeitig (im Gegensatz) zu Qt aber auch wirklich die gewählt Sprache verwendet, Trennung von Daten und GUI also einfach zu machen sind.

Für Qt gibt es auch Sprachbindings, allerdings sind es deutlich weniger und sie werden deutlich "Stiefmütterlicher" behandelt.

Daher habe ich meine Meinung mittlerweile geändert und ich halte Gtk+ für das technisch bessere Toolkit.

Was ist eure Meinung? Ihr könnt natürlich auch noch andere Toolkits in die Diskussion einbringen, ich wollte mich jetzt mal auf die zwei größten konzentrieren damit der Beitrag nicht zu lang wird.

 

[Sir Auron]

Also naja, ich bind eigentlich relativ fit in C (programmiere viele kleine - große Sachen rundum den Kernel und Arch Linux), aber GTK2 schaff ich auch nur mit Glade (habe kaum erfahrung mit GTK). GTK Funktionsnamen sind komisch, lang und nicht behaltbar, so wie das ganze Konzept selber (??). Desweiteren ist die Doku eigentlich mies, sieht man mal von der auf gtk-fr.org (Französisch [was ich nicht kann], aber mit google gehts [Die API Docu von gtk.org ist in Ordnung]) ab.

Zu QT kann ich als OOP-Hasser nichts sagen.

Wenn irgendjemand Dokumente für GTK Noops hat, dann her damit.

Achso wenn du GTK so gut findest solltest du GTKmm ausprobieren, das ist für C++.

 

[pinky]

Also naja, ich bind eigentlich relativ fit in C (programmiere viele kleine - große Sachen rundum den Kernel und Arch Linux), aber GTK2 schaff ich auch nur mit Glade (habe kaum erfahrung mit GTK). GTK Funktionsnamen sind komisch, lang und nicht behaltbar, so wie das ganze Konzept selber (??).

naja, die Funktionsnamen in C sind halt ziemlich lang. Dafür weiß man aber auch immer was sie bedeuten
Aber wie ich schon gesagt habe, eine Anwendung würde ich heute auch nichtmehr in Gtk-C schreiben. C ist als Basis für das Toolkit sicher eine gute Wahl gewesen aber für GUI-Anwendung würde ich eine höhere Sprache nehmen.

Zu glade, ich denke heute wird kaum noch jemand bei einer größeren GUI das Design per Hand schreiben. GUI-Builder haben durchaus ihren Sinn und sollten auch verwendet werden.

Desweiteren ist die Doku eigentlich mies, sieht man mal von der auf gtk-fr.org (Französisch [was ich nicht kann], aber mit google gehts [Die API Docu von gtk.org ist in Ordnung]) ab.

ich komme damit eigentlich ganz gut zurecht, vorallem auch mit der gtk# doku, obwohl diese an manchen Stellen noch sehr unvollständig ist, aber da kann man dann auf die Doku mit gtk+ oder gtkmm zurückgreifen, da es ja letztlich immer das gleiche ist.

Wenn irgendjemand Dokumente für GTK Noops hat, dann her damit.

kommt wie gesagt auch sehr stark darauf an in welcher Sprache du gtk+ nutzen willst. Wenn du in C programmieren willst, dann kann ich das Buch[1] empfehlen, habe ich selber auch und hat mir schon oft weiter geholfen.

Achso wenn du GTK so gut findest solltest du GTKmm ausprobieren, das ist für C++.

Habe ich mir auch schon angesehen. Allerdings gefällt mir daran nicht, dass es keine autoconnect Funktion für glade-Dateien gibt. D.h. ich muß jedes widget von Hand aus der xml Datei holen und verbinden. Sobald man da einigermaßen sinnvolle Programme schreibt sind das oft soviele widgets das zumindest mir der Spaß vergeht bis ich alle widgets heraus geholt und verbunden habe.

Was verwendest du dann? Oder machst du garnichts im GUI Bereich?

[1] http://www.bookzilla.de/shop/action/productDetails?aUrl=90006951&artiId=1475196

 

[oenone]

ja, gtkmm ist echt genial... hier mal die url: http://gtkmm.sourceforge.net/

auf bald
oenone

 

[pinky]

ja, gtkmm ist echt genial... hier mal die url: http://gtkmm.sourceforge.net/

geht auch einfacher: www.gtkmm.org

Nach deiner Aussage, gehe ich mal davon aus das du gtkmm benutzt:
Findest du es nicht nervig jedes widget, das du im Programm brauchst, erst in der header Datei zu definieren und dann noch in der cpp Datei aus der xml Datei zu holen und danach die Signale zu verbinden?

 

[Sir Auron]

Das Buch ist ja recht teuer, naja mal gucken, ob ich es mir besorge.

 

[avaurus]

ich hatte auch schon beides probiert und ich tendiere doch eher zu Qt, da es logischer aufgebaut ist. Bei GTK hab ich zum Beispiel immer das Problem, dass die einzelnen Komponenten nicht logisch miteinander verbunden sind.
Ich kann mich nur immer an die VCL festklammern, da dieses Modell das logischste von allen ist. Man definiert eine Komponente (widget) und kann von ihr eine Menge ableiten. wenn man zum Beispiel eine Listbox definiert, weiß man genau, dass die Listbox Items hat, also Listbox.items, und möchte man ein Item hinzufügen, schreibt man Litsbox.item.add(string), wobei man bei gtk schreiben würde (nur so ähnlich) , ItemAdd(objekt). Das ist zwar nicht so schlecht, aber man kann sich sowas viel schlecter einprägen und während man programmiert , hat man ja nicht gerade Lust, wieder nachzusehen, wie das heißt.
Bei Qt hält sich das noch alles in Grenzen, aber ok.

Dass es für GTK mehr Bindings gibt, stimmt, ja, aber wenn man sich diese Bindings mal genauer ansieht, ist es oft so, dass diese Bindings strikt übersetzt wurden, also keinerlei Gebrauch von den sprachlichen Features machen wie zum Beispiel OO und dann bringt mir auch das Binding nichts, weil ich dann in meiner Sprache wieder eigene Klassen schreibe, die die GTK-Klasse kapselt und handled. Und dann hab ich auch wieder Extraarbeit, die nicht sein muss.

Am Ende muss ich aber sagen, dass GTK kostenlos ist, Qt hingegen nicht und auch die Lizenzkosten von Qt kann ich als Privatperson leider nicht bezahlen (außer ich lege meine Quellen offen, dann kostet mich das 0 EUR).

 

[MrFenix]

Auch wenn mich das jetzt wahrscheinlich disqualifiziert... aber ich halte gambas für genial wenn man kleine (1-2 Formulare) GUIs proggen will, weils die simpelste syntax hat. Das einzige problem dabei ist halt, dass man bei gambas nicht grade von standart ausgehen kann und die sachen dann nicht wirklich tauglich für die Öffentlichkeit sind. Selbstverständlich sollte man die zugehörigen Programmfunktionen in C/C++ schreiben...

 

[pinky]

Ich kann mich nur immer an die VCL festklammern, da dieses Modell das logischste von allen ist. Man definiert eine Komponente (widget) und kann von ihr eine Menge ableiten.

kannst du bei gtk auch. Das ist bei C zwar etwas komplizierter, wird bei der verwendung von Sprachen die OOP besser unterstützen aber genauso einfach wie bei Qt (Beispiel gtkmm oder gtk#)

wenn man zum Beispiel eine Listbox definiert, weiß man genau, dass die Listbox Items hat, also Listbox.items, und möchte man ein Item hinzufügen, schreibt man Litsbox.item.add(string), wobei man bei gtk schreiben würde (nur so ähnlich) , ItemAdd(objekt).

Gerade mal nachgesehen, da ich etwas anderes in Erinnerung hatte...
Bei Qt schreibts du auch listbox.insertItem(QListViewItem)
Ist also vergleichbar mit gtkmm.

Dass es für GTK mehr Bindings gibt, stimmt, ja, aber wenn man sich diese Bindings mal genauer ansieht, ist es oft so, dass diese Bindings strikt übersetzt wurden, also keinerlei Gebrauch von den sprachlichen Features machen wie zum Beispiel OO und dann bringt mir auch das Binding nichts, weil ich dann in meiner Sprache wieder eigene Klassen schreibe, die die GTK-Klasse kapselt und handled. Und dann hab ich auch wieder Extraarbeit, die nicht sein muss.

stimmt so nicht. In gtkmm sind die widgets genauso C++ Klassen wie bei Qt und können genauso beliebig abgeleitet werden.

Am Ende muss ich aber sagen, dass GTK kostenlos ist, Qt hingegen nicht und auch die Lizenzkosten von Qt kann ich als Privatperson leider nicht bezahlen (außer ich lege meine Quellen offen, dann kostet mich das 0 EUR).

Das ist für mich persönlich kein Kriterium. Beide sind Freie Software, das reicht mir.

Da du Qt benutzt würde mich deine Antwort auf meine Kritik im ersten Beitrag interessieren (wo du zustimmst oder was du anders siehst bzw wie du die "Probleme" einschätzt).

 

[pinky]

Das Buch ist ja recht teuer, naja mal gucken, ob ich es mir besorge.

Für Fachbücher finde ich bewegt es sich eher im unteren Preissegment.
Das Buch gehört bestimmt zu dem besten was du zu gtk2 bekommen kannst und ist dazu noch in deutsch.
Also wenn du wirklich Gtk+ in C programmieren willst und mit dem was man so im Netz findet nicht zufrieden bist ist das Geld mMn wirklich gut investiert.

EDIT:
Hier gibt es auch eine Leseprobe, wenn du es dir mal etwas ansehen willst: http://www.galileocomputing.de/kata...itelID-356?GalileoSession=55948263A11Cf14HlEg

 

[Sir Auron]

Für Fachbücher finde ich bewegt es sich eher im unteren Preissegment.
Das Buch gehört bestimmt zu dem besten was du zu gtk2 bekommen kannst und ist dazu noch in deutsch.
Also wenn du wirklich Gtk+ in C programmieren willst und mit dem was man so im Netz findet nicht zufrieden bist ist das Geld mMn wirklich gut investiert.

EDIT:
Hier gibt es auch eine Leseprobe, wenn du es dir mal etwas ansehen willst: http://www.galileocomputing.de/kata...itelID-356?GalileoSession=55948263A11Cf14HlEg

Ist ja ganz nett, werd es mir kaufen wenn ich Kernel Architektur komplett gelesen und verstanden habe.

 

[oenone]

Nach deiner Aussage, gehe ich mal davon aus das du gtkmm benutzt:
Findest du es nicht nervig jedes widget, das du im Programm brauchst, erst in der header Datei zu definieren und dann noch in der cpp Datei aus der xml Datei zu holen und danach die Signale zu verbinden?

hm... soo arg hab ich mich noch nicht mit GUI programmierung beschäftigt.. aber bisher war ich positiv davon überrascht.

auf bald
oenone

 

[avaurus]

Da du Qt benutzt würde mich deine Antwort auf meine Kritik im ersten Beitrag interessieren (wo du zustimmst oder was du anders siehst bzw wie du die "Probleme" einschätzt).

Als ich deine Kritik gelesen hatte, hab ich das genauso empfunden. Das ist in der Tat so, wie du es schreibst. Wenn man sich seine Programme am Ende ansieht, stellt man wirklich fest, dass man sich in die Abhängigkeit von Qt begeben hat, nur finde ich es in diesem Moment nicht so schlimm, was aber auch daran liegt, dass meine Software einen ganz anderen Wert und eine ganz andere Wichtigkeit hat. Was mich an deiner Kritik verdutzt hat, war, dass du Portabilität angesprochen hast und ich dachte erst, von einem Betriebssystem zum anderen portieren, aber als ich dann weitergelesen hatte, stellte ich fest, dass du portieren im Sinne von einem Toolkit zum Anderen meintest und da hast du dann natürlich völlig Recht. Wenn man mit Qt arbeitet, und auch alles das benutzt, was Qt bietet, ist es rel. viel Arbeit diesen Qt-Code nach GTK zu portieren. Ich denke aber, dass dieses Problem nicht wirklich zu einem Problem wird, außer man war sich von Beginn der Planung nicht ganz sicher, was man als Toolkit verwendet.

 

[pinky]

Wenn man mit Qt arbeitet, und auch alles das benutzt, was Qt bietet, ist es rel. viel Arbeit diesen Qt-Code nach GTK zu portieren. Ich denke aber, dass dieses Problem nicht wirklich zu einem Problem wird, außer man war sich von Beginn der Planung nicht ganz sicher, was man als Toolkit verwendet.

Naja, wenn man nur sein Programm im Auge hat ist es sicher nicht so tragisch (auch wenn es natürlich gegen die grundlegenden Designprinzipien verstößt wie sie in vielen Standardwerken erklärt werden).
Ich denke es sollte aber trotzdem immer versucht werden so weit wie möglich Plattform und Toolkit unabhängig zu programmieren, da es dann eben leichter ist ein gnome, kde,... front-end zu entwickeln ohne jedesmal das Rad neu erfinden zu müssen. Um mal ein Beispiel zu nennen, k3b, hätte man da eine saubere Trennung zwischen GUI und Daten gemacht, hätte man die "Brennklassen" realtiv einfach in einem gtkmm Projekt verwenden können und hätte auch ein gutes Brennprogramm für gnome mit der gleiche Codebasis wie das KDE Programm was zu weniger Arbeit und höherer Qualität auf beiden Seiten führen würde.

Auf der gtk+ Seite finde ich die Trennung besser, da gibt es ganz klar das GUI Toolkit und die Programmiersprache. Wenn die Programmiersprache nicht das bietet was man will, dann versucht GTK nicht die Programmiersprache zu erweitern sondern dann bietet man dem Programmierer bindings an, so das er Gtk mit der Programmiersprache verwenden kann die das kann was er will. Auf der anderen Seite ist man bei Qt sehr stark auf C++ fixiert, was dazu führt, dass man versucht C++ zu erweitern wenn etwas nicht so funktioniert wie man es gerne hätte.
Nur dadurch könnte man sagen entsteht fast eine neue Programmiersprache, man begibt sich in starke Abhängigkeiten und die Wiederverwendbarkeit (über die Toolkit Grenzen hinweg, was unter GNU-,BSD- und Unix-Systemen nicht unwichtig ist) geht gegen Null.

Vielleicht ist das auch ein Grund, warum viele allgemeinen libs eher aus der gtk/gnome Ecke kommen (z.B. gstreamer oder libburn).

 

[thorus]

Dass es für GTK mehr Bindings gibt, stimmt, ja, aber wenn man sich diese Bindings mal genauer ansieht, ist es oft so, dass diese Bindings strikt übersetzt wurden, also keinerlei Gebrauch von den sprachlichen Features machen wie zum Beispiel OO und dann bringt mir auch das Binding nichts, weil ich dann in meiner Sprache wieder eigene Klassen schreibe, die die GTK-Klasse kapselt und handled. Und dann hab ich auch wieder Extraarbeit, die nicht sein muss.

Wie pinky bereits erwähnte stimmt das nicht. Nicht nur bei gtkmm wurde von den sprachlichen Features Gebrauch genommen, sondern auch in PyGTK, den Python-Bindings von GTK+, die ich sehr gerne benutze.
GTK+ mag durch die in C geschriebene Codebase von aussen nicht objektorientiert aussehen, da C ja bekanntlich syntaktisch von Haus aus keine Objektorientierung unterstützt, wenn man jedoch mal in C damit gearbeitet hat, erkennt man erst, wie objektorientiert es sein kann. Durch Strukturschachtelung und einigen Makros kann man so beispielsweise Vererbung realisieren (siehe http://developer.gnome.org/doc/API/2.0/gtk/ch01.html), wobei man natürlich mehr schreiben muss (z.B. im Extremfall gtk_widget_show(GTK_WIDGET(blubb)) statt blubb.show()).

Auf der gtk+ Seite finde ich die Trennung besser, da gibt es ganz klar das GUI Toolkit und die Programmiersprache. Wenn die Programmiersprache nicht das bietet was man will, dann versucht GTK nicht die Programmiersprache zu erweitern sondern dann bietet man dem Programmierer bindings an, so das er Gtk mit der Programmiersprache verwenden kann die das kann was er will. Auf der anderen Seite ist man bei Qt sehr stark auf C++ fixiert, was dazu führt, dass man versucht C++ zu erweitern wenn etwas nicht so funktioniert wie man es gerne hätte.
Nur dadurch könnte man sagen entsteht fast eine neue Programmiersprache, man begibt sich in starke Abhängigkeiten und die Wiederverwendbarkeit (über die Toolkit Grenzen hinweg, was unter GNU-,BSD- und Unix-Systemen nicht unwichtig ist) geht gegen Null.

Sehr guter Punkt. Diesen Gedanken kann man noch etwas weiter spinnen.

Ein Nachteil von Qt speziell im C++ Bereich sehe ich in der konsequenten Nichtbenutzung der STL. Natürlich kann man jetzt sagen, dass Qt bereits vorher entwickelt wurde, aber das ist kein Grund, dass sie noch heute auf eine eigene Insellösung zurückgreifen. Genau das macht die Trennung von UI und den normalen Funktionen schwierig, da eine dauernde Konvertierung von Nöten ist. Was nützt der beste QString, wenn ich einen String brauche?
Bei konsequenter Anwendung der STL, wie es etwa bei gtkmm der Fall ist, treten keine solchen Probleme auf, sofern andere Toolkits bzw. externe Libararies natürlich auch von der STL Gebrauch machen, was in der Regel der Fall ist.

Natürlich deckt Qt sehr viele Funktionen ab, Netzwerk, SQL, ja sogar XML-Parsing und vieles mehr ist dabei, doch ist dies wirklich wünschenswert?
Ist es sinnvoll eine große, fette Library mit vielen Funktionen zu benutzen, wenn es eine Library gibt, die für meinen speziellen Zweck flexibler, leicher einzubinden oder aus welchen Grund auch immer vorteilhafter für mich ist? Ich denke nicht.

Modularer Aufbau ist der Schlüssel zum Erfolg. Und genau hier kommt auch wieder die STL ins Spiel.
Kleiner Vergleich: http://gtkmm.sourceforge.net/download.shtml <> http://www.trolltech.com/download/qt/x11.html
So viel zum Thema Modularität.

Wie sagt doch ein bekanntes Sprichwort: Standards sind was feines. Jeder kann seinen eigenen machen.

 

[pinky]

Natürlich deckt Qt sehr viele Funktionen ab, Netzwerk, SQL, ja sogar XML-Parsing und vieles mehr ist dabei, doch ist dies wirklich wünschenswert?

genau das meinte ich, da versucht man aus C++ etwas zu machen was es nicht ist.
Es kann ja gut sein das man diese Sachen braucht, aber dann in meinen Augen nicht auf der Basis eines GUI Toolkits sondern auf der Basis einer Programmiersprache. So ein ganzes Framework kann ich nämlich mit Gtk+ auch haben, indem ich als Programmiersprache java oder mono/c# wähle. Dann habe ich den "Luxus" eines kompletten Frameworks, programmiere aber weiterhin "sauber" in der gewählten Sprache.

Wie gesagt, diese ganzen Gedanken sind mir auch erst mit der Zeit gekommen, anfangs war ich auch ein "Qt Fan". Aber mit der Zeit merkt man einfach, vorallem wenn man mit anderen Leuten spricht die z.B. in diesem Fall auch C++ programmieren, dass man mit Qt irgendwie zu einem "Insel-Programmierer" wird und das hat mich doch sehr abgeschreckt.

Ist es sinnvoll eine große, fette Library mit vielen Funktionen zu benutzen, wenn es eine Library gibt, die für meinen speziellen Zweck flexibler, leicher einzubinden oder aus welchen Grund auch immer vorteilhafter für mich ist? Ich denke nicht.

Modularer Aufbau ist der Schlüssel zum Erfolg. Und genau hier kommt auch wieder die STL ins Spiel.

Kleiner Vergleich: http://gtkmm.sourceforge.net/download.shtml <> http://www.trolltech.com/download/qt/x11.html
So viel zum Thema Modularität.

Wobei man fairerweise sagen muß, dass Qt4 auch modular in mehrere Teile zerlegt wird. U.a. kann man dann die ganzen QString, Netzwerk, Datenbank,... Sachen usw auch ohne dem GUI-Teil benutzen, was sich auf den ersten Blick schön anhört letztlich aber das Insel dasein nur noch mehr fördert, da man dann nur darauf warten kann bis es die ersten Konsolenprogramme gibt, von Leuten die Qt von der GUI Programmierung gewöhnt sind, die Qt brauchen.

 

[miketech]

Hi,

heiße Diskussion Also um mich auch mal einzumischen: Qt ist wirklich mehr als ein einfaches GUI Toolkit, aber das finde ich gar nicht schlimm. Es ermöglicht mir z.B. plattformunabhängige Netzwerk- oder Multithread-Anwendungen zu schreiben. Die STL alleine bietet mir diese Funktionen nicht und auch sonst bietet Qt an einigen Stellen mehr als die STL.

Ich persönlich sehe Qt manchmal als Java-Ersatz. Java ist eine nette Sache, hat mir jedoch persönlich nie gefallen, sobald es um GUIs ging. C++ fand ich hingegen nett, manchmal jedoch etwas kompliziert. Mit Qt erreiche ich mit C++ die Einfachheit, die mir sonst z.B. Java bietet. Ein logischer Aufbau von Methoden.

Also ich stimme daher zu, dass es mehr als nur ein GUI-Toolkit ist und man sich auch sehr schnell in die Abhängigkeit von Qt begibt, sobald man ein Programm damit anfängt. Auf die Elemente der STL wird kaum noch zurückgegriffen, da Qt einem alles bietet. Aber wieso sollte ich noch die STL verwenden? Wenn ich Elemente von Qt benutze, muss der User eh Qt installiert haben, dann kann ich auch gleich die Bequemlichkeit der anderen Elemente von Qt nutzen, wie QStrings und Co.

Ich habe mir damals auch GTK angeschaut und fands einfach nur grauslig Schon alleine die Namensgebung der Funktionen wie "ich_bin_ein_button_zum_klicken_mit_grünem_rand" fand ich furchtbar. Ebenso kam ich mit wxWidgets überhaupt nicht klar. Bei Qt hingegen habe ich mich sofort wohl gefühlt, weil alles logisch aufgebaut war und mir sehr vertraut vorkam. Dazu kam, dass sich meine Qt Programme bei mir als KDE-User ideal integriert haben.
Mit gtkmm hingegen habe ich mich jetzt noch nicht beschäftigt, ich blättere grad nebenbei in der Doku.

Was mich dabei direkt interessieren würde: Inwiefern arbeitet denn GTK mit der STL zusammen? Ich hatte immer in Erinnerung, dass es bei GTK auch eigene gtk-Strings gab, oder irre ich mich?

Noch etwas, was ich dabei nicht verstehe: In welchem Zusammenhang stehen atk gdk, gtk, und pango?


Also wer wirklich eine reine GUI-Anwendung schreiben möchte und dabei mit allen Funktionen plattformunabhängig programmieren möchte (Threads, Sockets usw.) ist mit Qt auf jeden Fall gut bedient (Lizenzkosten seien mal dahingestellt). Mir gefällts auf jeden Fall super

Gruß

Mike

 

[thorus]

heiße Diskussion Also um mich auch mal einzumischen: Qt ist wirklich mehr als ein einfaches GUI Toolkit, aber das finde ich gar nicht schlimm. Es ermöglicht mir z.B. plattformunabhängige Netzwerk- oder Multithread-Anwendungen zu schreiben. Die STL alleine bietet mir diese Funktionen nicht und auch sonst bietet Qt an einigen Stellen mehr als die STL.

Und da man nie alles braucht, gibt es ja spezielle Libraries dafür. Die STL sollte auch nur einen Grundstock bieten.

Aber wieso sollte ich noch die STL verwenden? Wenn ich Elemente von Qt benutze, muss der User eh Qt installiert haben, dann kann ich auch gleich die Bequemlichkeit der anderen Elemente von Qt nutzen, wie QStrings und Co.

Den Punkt habe ich vorher schon angesprochen. Wenn du in deinem Programm Konsequent die Q-Objekte verwendest musst du, wenn du z.B. auf gtkmm portierst, immer diese Typen umwandeln. Das ist nicht nur Schreibarbeit, sondern auch Prozessorarbeit.
Wenn man hingegen sowieso die STL verwendet, sowohl in UI als auch im Kern deines Programmes, fällt diese Konvertierung weg. Genau aus diesem Grund gibt es die STL.

Ich habe mir damals auch GTK angeschaut und fands einfach nur grauslig Schon alleine die Namensgebung der Funktionen wie "ich_bin_ein_button_zum_klicken_mit_grünem_rand" fand ich furchtbar.

Du musst aber faiererweise dazusagen, dass es sich hierbei um C handelte. Und soooo schlimm ist es auch wieder nicht.. Beispiel:

GtkWidget *button;
button = gtk_button_new_with_label("Button 1");
gtk_widget_show(button);

oder alternativ, wenn man du dieses with vermeiden willst:

GtkWidget *button;
button = gtk_button_new();
button = gtk_button_set_label("Button 1");
gtk_widget_show(button);

Dieses with_X ist nur eine Hilfe, denn wie du siehst, müsste man sonst noch mehr schreiben. Aber wir driften nach C ab.

Was mich dabei direkt interessieren würde: Inwiefern arbeitet denn GTK mit der STL zusammen? Ich hatte immer in Erinnerung, dass es bei GTK auch eigene gtk-Strings gab, oder irre ich mich?

Das beispielsweise in C so. Da liefert die Glib den Typ GString. Unter C finde ich die Einführung eines neuen Typs zwangs Mangel im Standard, für sinnvoll, in C++ jedoch nur begrenzt (siehe unten). Beispielsweise beinhaltet die Glib noch verkettete Listen, Queues, Bäume und noch viel mehr Sachen, für die in keinem C-Standard vorhanden sind.
Im Falle von C++ trifft dies jedoch wegen der STL nicht zu.

In gtkmm bzw. glibmm gibt es aber tatsächlich einen eigenen String namens Glib::ustring. Wie das u schon andeutet ist damit Unicode-Support, Konvertierung zwischen Locales usw. gemeint. Gut, QString kann das auch, war vielleicht ein schlechtes Beispiel meinerseits. In dem Fall wurde std::String erweitert, was ich persönlich für sinnvoll halte.
Ich verweise dich in dem Fall mal auf die gtkmm FAQs, weil dort der Zusammenhang auch in Bezug auf Glib::ListHandle vs. std::list und std::vector sehr schön beschrieben ist: http://www.gtkmm.org/docs/gtkmm-2.4/docs/FAQ/html/index.html#id2486895

Noch etwas, was ich dabei nicht verstehe: In welchem Zusammenhang stehen atk gdk, gtk, und pango?

atk = Erweiterungen für Behinderte
gdk = Grafik
gtk = Gestaltung der UIs an sich
pango = Textrenderer

 

[pinky]

heiße Diskussion Also um mich auch mal einzumischen: Qt ist wirklich mehr als ein einfaches GUI Toolkit, aber das finde ich gar nicht schlimm. Es ermöglicht mir z.B. plattformunabhängige Netzwerk- oder Multithread-Anwendungen zu schreiben. Die STL alleine bietet mir diese Funktionen nicht und auch sonst bietet Qt an einigen Stellen mehr als die STL.

Aber damit erweiterst du eben eine Programmiersprache "zu etwas was es nicht ist". Wäre es nicht schlauer eine entsprechende (standardisierte) Programmiersprache/Framework zu verwenden anstatt eine Programmiersprache zu einer "Insellösung" zu erweitern?

Also ich stimme daher zu, dass es mehr als nur ein GUI-Toolkit ist und man sich auch sehr schnell in die Abhängigkeit von Qt begibt, sobald man ein Programm damit anfängt. Auf die Elemente der STL wird kaum noch zurückgegriffen, da Qt einem alles bietet. Aber wieso sollte ich noch die STL verwenden?

Unabhängigkeit? Dann kannst du Klassen schreiben, die deine Daten verwalten und diese mit Qt, gtk, ncurses, konsolen und sonstigen GUIs verwenden?
Das mag nicht so wichtig sein solange du für dich ein paar "hello-world Programme schreibst". Wenn du aber etwas größeres machst, mit dem du zur Free Software Community beitragen willst oder für dich selber eine hohe Wiederverwendbarkeit haben willst, dann sieht das ganz schnell anders aus.

Ich habe mir damals auch GTK angeschaut und fands einfach nur grauslig Schon alleine die Namensgebung der Funktionen wie "ich_bin_ein_button_zum_klicken_mit_grünem_rand" fand ich furchtbar.

wie schon gesagt wurde ist es nicht fair, da du hier nicht die Toolkits vergleichst, sondern Programmiersprachen (auch wenn für Qt Programmierer die Grenzen da oft verfließen ).
Schauen wir uns doch mal C++ an, um die gleiche Programmiersprache zu verwenden:

Qt:

#include <qapplication.h>
#include <qpushbutton.h>


int main( int argc, char **argv )
{
    QApplication a( argc, argv );
    QPushButton hello( "Hello world!", 0 );
    hello.resize( 100, 30 );
    a.setMainWidget( &hello );
    hello.show();
    return a.exec();
}

Gtkmm:

#include <gtkmm.h>

int main(int argc, char *argv[])
{
    Gtk::Main kit(argc, argv);
    Gtk::Button button("Hello World!");
    Gtk::Window window;
    window.add(button);
    button.show();
    Gtk::Main::run(window);

    return 0;
}

Also ich würde nicht behaupten, dass der Qt code "schöner" ist als der Gtkmm code. Ich würde eher sogar sagen, dass sich der gtkmm code für eine C++ Programmiere (und das sollte die meisten sein die sich ein C++-Toolkit aussuchen ) vertrauter anfühlt.

Und genauso sieht es mit andere Programmiersprachen aus, hier z.B. c#

using Gtk;

class HelloWorld
{
    static void Main (string[] args)
        {
            Application.Init();
            Window window = new Window("Hello");
            Button button = new Button("Hello World");
            window.Add(button);
            window.ShowAll();
            Application.Run();
        }
}

oder perl:

use Gtk;
init Gtk;

my $window = new Gtk::Window( "toplevel" );
add $window (my $label = new Gtk::Label "Hello, World!");
$window->show_all();
main Gtk;

Hier könnte man jetzt mit beliebigen anderen Programmiersprachen weiter machen.

Wie man sieht, passt sich Gtk immer der Programmiersprache an und nicht umgekehrt. Dadurch kann man die Programmiersprache oder das Framework verwenden was einem am besten gefällt und damit seine Daten verwalten, dieser code ist dann immer in der jeweiligen Programmiersprache und kann universell verwendet werden. Danach kann man Gtk nehmen und in dem syntax der gewählten Programmiersprache eine schöne GUI bauen.
In meinen Augen eine Ideale Situation und der Schlüsslepunkt der für mich Gtk mittlerweile zum technisch besseren Toolkit macht.

Also wer wirklich eine reine GUI-Anwendung schreiben möchte und dabei mit allen Funktionen plattformunabhängig programmieren möchte (Threads, Sockets usw.) ist mit Qt auf jeden Fall gut bedient (Lizenzkosten seien mal dahingestellt). Mir gefällts auf jeden Fall super

du bist dann so Plattformunabhängig wie Qt ist. Noch viel Plattformunabhängiger wirst du wenn du sauber Daten und GUI trennst. Dann kann man den Hauptteil des Programms (Datenimplementierung) überall verwennden, z.B. auch in einem VC++ Projekt unter windows, in einem Gtk Projekt, in einem Konsolenprogramm,....

 

[miketech]

Hi,

hm, also ich habe vor kurzem folgende Probleme festgestellt:

Ich bin derzeit dabei mich etwas in Ruby einzuarbeiten. Hier bietet mir Ruby alles, was ich brauche. Sockets, Threads usw. Es gibt auch Qt-Bindings für Ruby, allerdings war ich hier dann zum ersten mal etwas unentschlossen, ob ich nun die Qt-Sockets nehme, oder die Sockets von Ruby. Selbiges eben bei Threads. Ich habe also zwei Implementierungen für den selben Zweck, da mir das Toolkit mehr mitbringt, als ich benötige.

Dann gibt es für C++ noch die Boost-Library, die ja eventuell bald in den Standard aufgenommen werden soll (oder zumindest zum Teil). Hier hatte ich selbiges Problem: Wieder habe ich zwei Möglichkeiten meine Programme zu realisieren. Boost bietet mir auch Funktionen, wie Threads. Nehme ich nun die Boost-Library dafür, oder die Qt-Library?


Allerdings gibt es bei Boost keine Funktionen für Sockets. Mir ist auch sonst keine Bibliothek im C++ Standard bekannt, die Netzwerkprogrammierung ermöglicht. D.h. ich müsste wieder nach einer zusätzlichen Bibliothek schauen, die mir solche Funktionen bietet.

/* Auf der gtk.org - Seite gibt es bei der API-Reference noch Dokumentation zu glib. Was ist das? glib bietet auch wieder Funktionen, wie threads. */

Vielleicht brauche ich für eine andere Funktion dann noch eine andere Bibliothek und vielleicht laufen nur ein paar auch auf anderen Betriebssystemen.

Ist es dann nicht besser nur eine einzige Abhängigkeit (Qt) zu haben? Dann benötige ich wirklich nur Qt auf dem Fremdrechner und alle Funktionen stehen mir zur Verfügung und ich brauche keine X verschiedene Libraries mitschleppen.

Wie schon gesagt wurde wird Qt ab Qt 4 aufgeteilt in verschiedene Komponenten. Wer dann eben nur den Netzwerkteil benötigt, kann auch nur diesen verwenden und brauch nie das komplette Qt einbinden.

Gruß

Mike