PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : GUI Programmierung: Toolkit vergleich



pinky
01.01.2005, 18:46
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
01.01.2005, 19:20
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
01.01.2005, 19:38
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
01.01.2005, 19:46
ja, gtkmm ist echt genial... hier mal die url: http://gtkmm.sourceforge.net/

auf bald
oenone

pinky
01.01.2005, 19:52
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
01.01.2005, 20:09
Das Buch ist ja recht teuer, naja mal gucken, ob ich es mir besorge.

avaurus
01.01.2005, 20:45
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
01.01.2005, 21:03
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
01.01.2005, 21:06
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
01.01.2005, 21:10
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/katalog/buecher/titel/gp/titelID-356?GalileoSession=55948263A11Cf14HlEg

Sir Auron
01.01.2005, 21:56
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/katalog/buecher/titel/gp/titelID-356?GalileoSession=55948263A11Cf14HlEg
Ist ja ganz nett, werd es mir kaufen wenn ich Kernel Architektur komplett gelesen und verstanden habe.

oenone
01.01.2005, 22:29
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
01.01.2005, 22:55
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
01.01.2005, 23:13
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
02.01.2005, 01:51
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
02.01.2005, 02:34
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
02.01.2005, 03:05
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
02.01.2005, 11:07
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
02.01.2005, 16:10
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
08.01.2005, 18:21
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

miketech
08.01.2005, 18:34
Ach und noch etwas: Vielleicht sollte man auch mal die GUIs an sich betrachten:

Afaik bietet Qt mehr GUI-Elemente mit mehr Möglichkeiten. Und mit KDE steht noch mehr zur Verfügung.

Auch so Sachen, wie der File-Dialog: Der ist bei GTK ja wohl ziemlich arm. Der von Qt an sich ist auch nicht so super, stimmt, aber wenn man KDE nutzt und auf die KDE Bibliotheken zurückgreift ist da schon ein großer Unterschied. Und auch vom Style her finde ich Qt wesentlich schicker, zumal es auch viel mehr brauchbare Styles gibt. Bei GTK schaut immer alles etwas unschön aus, oft grau in grau. Das ist auch der Grund, weshalb ich immer KDE benutze und kein Gnome. Weil mir der Gnome-Desktop einfach zu braun/grau und trübe aussieht.

Ich habe hier mehrere GTK-Programme und schon viele verschiedene Styles ausprobiert und nur wenige Styles gefallen mir. Teilweise kamen mir die GUIs auch langsamer vor, als bei Qt. Qt kommt mir also nicht nur schöner, sondern auch schneller vor und mit Qt4 soll sich an der Performance nochmal einiges tun.

Bei Qt tut sich also eine ganze Menge, während ich immer das Gefühl habe, dass bei GTK die Entwicklung ziemlich hängt. Wie lange mussten die Leute auf einen etwas verbesserten File-Dialog warten und der neue ist nun nicht der Renner. Für mich macht es den Eindruck, als ob sich an der GUI von GTK nicht mehr viel ändert.

Das mag jetzt sehr stark nach Flame aussehen, aber das ist genau meine Meinung von GTK, die ich eben hier mal auf den Punkt bringe ;)

Gruß

Mike

pinky
08.01.2005, 19:36
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.


imho sollte man immer die implementierung der Programmiersprache nutzen, wenn sie es anbietet. Damit bist du einfach näher am Standard dran, Ruby Programmierer (auch die die mit Qt und GUI nichts am Hut haben) können deinen Code verstehen, ihn nutzen oder dir einfach helfen.

Wenn es bei der Sprache die libs nicht gibt, dann muß man eben immer abwegen.
Wenn es z.B. bei C++ eine saubere und Plattformunabhängige lib gibt die weit verbreitet ist, dann würde ich sie der Qt implementierung vorziehen, einfach um sauber Daten/GUI trennen zu können. Wenn das nicht geht spricht auch nichts dagegen wenn du die Qt Implementierung nimmst oder bei Gtk-C das was du in der glib findest. Aber imho sollte an erster Stelle immer das Toolkit unabhängige stehen was der Standardsprache am nächsten ist.



/* 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. */


ja, bei Gtk gibt es zum Teil auch Erweiterungen, ich habe ja auch nicht gesagt, dass prinzipiell alle Erweiterungen schlecht sind.
Der Unterschied ist für mich, dass bei Qt C++ immer weiter aufgeblasen wird und jemand der täglich mit Qt programmiert wohl die einen oder anderen "Kommunikationsprobleme" mit C++ Programmierern bekommt, da sich in meinen Augen Qt immer mehr zu einer eigenen Programmiersprache entwickelt.
Bei Gtk hat man natürlich C auch an der eine oder anderen Stelle etwas "aufgebohrt", wo es nötig war, aber danach hat man saubere Anbindungen an verschiedene Programmiersprachen und jeder kann sich die Programmiersprache aussuchen die am besten zu seiner Aufgabe passt.

In den letzten Tagen habe ich auch noch ein schönes Beispiel gefunden, ich habe mir mal die Qt# bindings angesehen:

Ich muß sagen ich bin ehrlich gesagt etwas erschrocken, wenn man sich nur den Programmcode ansieht (also nicht das drum herum (klassen definition, using,...)) könnte man meinen man schaut sich ein C++ Programm an, also eigentlich das was du den Gtk bindings vorgeworfen hast (lieblos ohne Anpassung auf die Sprache aufgesetzt).
C# bietet eine einfachen Mechanismus um Signale zu verbinden und auch Datei Operationen die mind. so einfach sind wie die von Qt. Aber sobald ich unter C# mit Qt anfange werden QFiles verwendet, Signale werden mit dem gleichen Synatx wie unter C++ verbunden,...
Gtk# hat sich dagegen schön in C# eingebunden und passt sich dem Syntax an und verwendet das was C# einem schon bietet.
Das verstärkt nur wieder meine These: Qt hat sich zu einer eigenen Programmiersprache entwickelt die man über C++ drüber gestülpt hat und z.B. bei den C# Bindings über C# drüber stülpt. Man programmiert aber kaum noch C++ oder C# sondern jedesmal Qt.
GTK ist dagegen ein sauberes Toolkit das man mit vielen Programmiersprachen nutzen kann und das sich immer der Programmiersprache anpasst.

Zu deinem zweiten Beitrag:
Das dir der gnome filedialog nicht gefällt macht das Toolkit weder schlecht noch gut.
Das sind alles rein subjektive Empfindungen, ein gnome/gtk Anwender würde genau das gleiche schreiben nur umgekehrt und beidesmal wäre es genauso falsch wie richtig und würde beidesmal genauso viel/wenig über die Qualität des Toolkits aussagen.

EDIT: Ich habe mir gerade mal Qt-Ruby angesehen, was ich zumindest positiv finde ist, dass man es da endlich mal gschafft hat Qt einen eigenen namespace zu geben. Das wäre imho auch mal bei C++ angebracht.

miketech
08.01.2005, 22:43
Naja, aber was nützt es mir, wenn ein Toolkit zwar vom Modell her besser aufgebaut zu sein scheint, aber von den Leistungen nicht den Erwartungen entspricht? Das ist wie mit tcl/tk. Das wird auch immer seltener eingesetzt, weils den optischen Erwartungen nicht mehr gerecht wird. Sicherlich kann man darüber streiten, ob GTK nun schön oder hässlich ist. Aber, dass die Entwicklung sehr langsam von statten geht und dass es sowohl optisch, als auch von der Leistung Qt hinterherhinkt ist für mich ziemlich sicher. Meine GTK-Anwendungen sind von der GUI her alle viel träger, als z.B. Qt-GUIs. Und wenn ich schon eine Anwendung mit GUI schreibe, dann mach ich das, weils auch schick aussehen und schön und schnell zu bedienen sein soll.

Und zu den Styles: Ich habe 2 Styles, die mir bei GTK recht gut gefallen. Allerdings sind diese, wie gesagt etwas langsam. Dazu kommt, dass ich z.B. bei KDE Styles habe und dann noch die Farben einstellen kann. Bei GTK bestimmt der Style die Farbe. Mir fehlt da Flexibilität, was mir eben den Eindruck gibt, dass GTK hinter Qt herhinkt. Selbiges bei Gnome: Bei KDE sehe ich bei einem neuen Release, was sich getan hat. Bei Gnome scheint alles sehr träge zu sein, da finde ich fast keinen Unterschied zwischen Gnome 2.4 und 2.8. Aber das ist auch wieder subjektiv und gehört nun nicht hierher.

Kennst Du denn C++ Libraries für Socketprogrammierung? Also Libraries, die plattformunabhängig sind?

Also QtRuby gefällt mir soweit recht gut. Allerdings hatte ich am Anfang ähnlichen Effekt, wie Du bei C#. Mein erstes QtRuby Programm sah aus wie selbiges in C++ mit ein paar Änderungen. Aber was sollte man auch groß ändern. Die GTKRuby Programme sehen auch aus wie die GTK Programme mit C++, weils eben dieselben Klassen sind. Ich weiß nicht, wie es bei Dir bei C# aussah, damit es C++ ähnlicher ist, als GTKRuby, oder QtRuby.

Gruß

Mike

pinky
08.01.2005, 23:17
Naja, aber was nützt es mir, wenn ein Toolkit zwar vom Modell her besser aufgebaut zu sein scheint, aber von den Leistungen nicht den Erwartungen entspricht?


Was sind deine Erwartungen an ein GUI Toolkit? Ich erwarte, dass es mir alles in die Hand gibt um einfach und schnell GUIs zu erstellen. Ich würde sagen da fehlt weder bei Qt noch bei Gtk etwas.
Man könnte die Erwartung etwas erweitern: Weiter sollte es möglichst unabhängig von der Programmiersprach sein. So das ich, wie bei Konsolenprogrammen, die Programmiersprache je nach Aufgabe wählen kann und immer in der Lage bin eine GUI drauf auf zu setzen.
Mit der Erweiterung würde ich sagen geht ein ganz klares Plus an Gtk+ ;)



Sicherlich kann man darüber streiten, ob GTK nun schön oder hässlich ist. Aber, dass die Entwicklung sehr langsam von statten geht


was verstehst du unter langsam?
Gtk entwickelt sich mind. so schnell wie Qt und wenn du bei Qt mal die "C++ Verbesserungen" weg lässt, dann tut sich bei den neuen Qt releases auch nicht mehr als bei den Gtk releases. Wobei ich nicht sagen will das es wenig ist was sich da tut.
Aber wenn wir schon auf Oberflächlichkeiten herum reiten, auch wenn ich das für falsch halte, gibt es z.B. bei Gtk schon ewig sogenannte stock-icons. D.h. wenn ich einen save, load, print, add, remove,... (halt lauter Standard sachen) Button anlege, dann bekommen sie bei Gtk ein schönes icon das sich auch dem Style anpasst und um die Übersetzung muß ich mich dann auch nichtmehr kümmern.
Bei Qt gibt es keine einheitliche Lösungs für Standardbutton mit icons+Text und Übersetzung.



Meine GTK-Anwendungen sind von der GUI her alle viel träger, als z.B. Qt-GUIs. Und wenn ich schon eine Anwendung mit GUI schreibe, dann mach ich das, weils auch schick aussehen und schön und schnell zu bedienen sein soll.


Bei mir sind Gtk und Qt Programme gleich träge bzw. flink.
Was das aussehen angeht, mal eine kleine Beobachtung von mir:
Wenn ich KDE benutze kommen mir Gtk Programme auch immer hässlich vor, benutze ich gnome oder xfce kommen mit Qt Programme hässlich vor. Ich denke das henkt zu einem großen Teil auch am Gesamtbild und das du als KDE benutzer dann Gtk als häßlich empfindest ist nicht verwunderlich. Trotzdem oder gerade deswegen ist es aber sehr subjektiv und sagt nichts über die Qualität des jeweiligen Toolkit aus.



Und zu den Styles: Ich habe 2 Styles, die mir bei GTK recht gut gefallen. Allerdings sind diese, wie gesagt etwas langsam.


das sind 2 mehr als ich bei Qt habe ;)
Im ernst, von den Qt styles gefällt mir garkeins, bei KDE finde ich plastik ganz in Ordnung, mit dem rest kann ich nichts anfangen.
Aber auch wenn ich mich wiederhole, wir driften auf Oberflächlichkeiten ab.



Selbiges bei Gnome: Bei KDE sehe ich bei einem neuen Release, was sich getan hat. Bei Gnome scheint alles sehr träge zu sein, da finde ich fast keinen Unterschied zwischen Gnome 2.4 und 2.8. Aber das ist auch wieder subjektiv und gehört nun nicht hierher.


Ja, bei KDE werden die Menus immer voller, bunter und unübersichtlicher. Ich finde 90% der Fälle die Gtk/gnome Programme schöner, aufgeräumter und funktionieller.
Aber du hast vollkommen recht, dass gehört absolut nicht hier her.



Ich weiß nicht, wie es bei Dir bei C# aussah, damit es C++ ähnlicher ist, als GTKRuby, oder QtRuby.


wenn z.B. Signal/Slots so verbunden werden wie du es von C++ kennst, obwohl C# seine eigenen (in meinen Augen sehr guten) Routinen dafür hat. Gtk# verwendet da die C# EventHandler, was u.a. dafür sorgt das sich gtk# sauber in C# eingliedert und sich für einen C# Programmierer bekannt anfühlt (da er bei allen anderen Programmen ja auch mit den C# EventHandlern arbeitet).
Das ist eben das was ich meine, eine ganz klare Aufgabe: GUI Toolkit. Und dann wird es in jeder Programmiersprache mit ihren typischen Mitteln eingebunden. Dadurch kann jeder Programmierer, egal ob C, C++, C#, Ruby, Perl, lisp,... auf seine gewohnte Programmierart eine GUI für sein Programm erstellen.

miketech
08.01.2005, 23:53
Hi,

ok da hast Du natürlich recht. Dadurch, dass ich KDE verwende, passen GTK GUIs nie optisch zum Rest.

Also ich habe mir eben nochmal GTKRuby etwas angeschaut. Bisher habe ich überwiegend mit der Namensgebung von GTK-Funktionen Probleme gehabt, wie in einem meiner früheren Beiträge erwähnt. GTKRuby unterscheidet sich vom Handling her jedoch sehr wenig von QtRuby. Was mich jedoch immer noch stört: Klassen sind bei gtkmm so geschrieben: DiesIstEineKlasse. Methoden hingegehen: dies_ist_eine_methode. Das widerstrebt mir etwas, da es nicht die Namensgebung ist, die ich wähle. Ja, die Argumente werden langsam etwas dünn, aber ich recherchiere weiter :)

GTK ist ja eigentlich C, während gtkmm den objektorientierten Ansatz verfolgt, korrekt? Ich komm da etwas durcheinander, wo ich jetzt GTKRuby sehe. Ruby ist ja sehr stark objektorientiert. Müsste das dann nicht gtkmmruby sein? Oder ist gtkmm lediglich die objektorientierte Erweiterung für C++? Und Ruby macht da was eigenes für sich?


Wie schauts eigentlich mit wxWidgets aus? wxWidgets verwendet unter Linux GTK und unter Windows die Windows Libs. Damit schon Erfahrungen gemacht? Ich habs mal versucht, jedoch hat es mir wenig gefallen. Ich kam damit einfach nicht klar, weils mich nicht wirklich angesprochen hat und eine Sprache, oder ein Toolkit muss mich faszinieren, oder irgendwie reizen, damit ich mich privat damit beschäftige. wxWidgets ist objektorientierter, als das einfache gtk, daher hatte ich darauf einen Blick geworfen, weil ich gtkmm nicht kannte. Aber da GTK auch unter Windows läuft, sehe ich nicht die Vorteile von wxWidgets. Zeichnet GTK unter Windows selbst? Oder werden hier die Windows Libs genutzt? Läuft GTK unter Windows denn stabil? Hab da oft nichts positives gehört.

Ich denke ich werde die nächsten Tage, um mich weiter in Ruby einzuarbeiten mal einen Blick auf gtkruby werfen. Da hier ja ausschließlich die GUI-Klassen enthalten sind, kann ich weiterhin mit den Ruby-eigenen Funktionen spielen und gleichzeitig mit GTK mal etwas rumprobieren. Mal schauen, was ich nach ein paar Wochen GTK sage. Ich denke, es ist auch immer etwas Einarbeitung nötig, um ganz gezielt die Vorteile zu erkennen. Da ich mit GTK fast nie was zu tun habe, fehlt mir dies. Ich habe von Anfang an auf KDE gesetzt, nur kurze Zeit mit Gnome verbracht.

Dagegen, dass ein GUI - Toolkit ausschließlich GUI - Funktionalität bieten sollte, sage ich schon gar nichts mehr. Sobald man GUI und Daten voneinander trennt hat man bei Qt sicherlich Probleme, was die Abhängigkeiten angeht. Da hier schnell so Kleinigkeiten, wie String (STL) und QString (Qt) durcheinander geraten.

Allerdings sehe ich, wie schon gesagt noch den Vorteil von Qt, dass ich nur eine einzige Abhängigkeit habe und kein Baukastenprinzip.

Mike

pinky
09.01.2005, 00:36
Was mich jedoch immer noch stört: Klassen sind bei gtkmm so geschrieben: DiesIstEineKlasse. Methoden hingegehen: dies_ist_eine_methode. Das widerstrebt mir etwas, da es nicht die Namensgebung ist, die ich wähle.


ja, da hat jeder seinen eigenen Stil. Programmiersprachen und auch Toolkits sind halt auch immer etwas sehr individuelles dem einen liegt das eine und dem anderen das andere.
Ich persönlich finde die Unterstriche auch nicht so toll, aber die gtkmm Hacker scheinen es eben anders zu sehen, gtk# hat z.B. diese Unterstriche nicht und kommt mir zur Zeit sowieso am meisten bei der GUI Programmierung entgegen (auch wenn es die unseglichen .exe und .dll Endungen in die GNU Welt einführt).



GTK ist ja eigentlich C, während gtkmm den objektorientierten Ansatz verfolgt, korrekt?


zur hälfte ;)
GTK ist in C geschrieben, soweit richtig. Aber gtkmm ist nicht der "objektorientierten Ansatz" sondern die C++ Bindings für gtk+. gtkmm macht also nicht mehr als das es dir ermöglich Gtk+ in C++ auf die C++ typische Art zu verwenden.
Objektorientiert ist Gtk+ immer, auch unter C! Objektorientiert ist eine generelle Art zu programmieren und unabhängig von einer Programmiersprache.
Wobei es natürlich Programmiersprachen gibt die es begünstigen und Programmiersprachen wo man eher "tricksen" muß bzw. wo es vielleicht auch besser ist wenn man es garnicht erst versucht.
Ich würde z.B. nie versuchen in Gtk+ (also in C) eine eigene widget Klasse zu erstellen oder sogar von einer bestehenden abzuleiten. Das ist mir dann doch zu heftig, diese Basisarbeit überlasse ich gerne den Gtk+ Hackern und bediene mich dann an den "einfachen" Bindings für höhere Sprachen.



Ich komm da etwas durcheinander, wo ich jetzt GTKRuby sehe. Ruby ist ja sehr stark objektorientiert. Müsste das dann nicht gtkmmruby sein? Oder ist gtkmm lediglich die objektorientierte Erweiterung für C++? Und Ruby macht da was eigenes für sich?


Die Bindings entstehen immer aus GTK+, d.h. aus dem C Toolkit.
Also egal ob Gtkmm, GTKRuby, gtk#, PyGtk, CL-Gtk,... die Basis ist immer GTK+



Wie schauts eigentlich mit wxWidgets aus? wxWidgets verwendet unter Linux GTK und unter Windows die Windows Libs. Damit schon Erfahrungen gemacht? Ich habs mal versucht, jedoch hat es mir wenig gefallen. Ich kam damit einfach nicht klar, weils mich nicht wirklich angesprochen hat und eine Sprache, oder ein Toolkit muss mich faszinieren, oder irgendwie reizen, damit ich mich privat damit beschäftige.


Ich selber habe nie mit wxwidgets gearbeitet.
wxwidget ist vielleicht leichter zu portieren, da es unter windows die windows GUI verwendet.
Auf der anderen Seite verwendet wxwidget unter GNU/Linux zwar Gtk um die GUI zu zeichnen, es ist aber nicht Gtk. Das merkt man daran, dass z.B. die Treeview oder Toolbar anders aussieht als bei Gtk anwendungen und auch ansonsten erkennt man einfach am Aufbau das es nicht wirklich Gtk ist. Dazu kommt dann natürlich auch, dass man es z.B. nie wirklich in gnome integrieren kann und gnome-libs verwenden kann und Styles haben auch so ihre Probleme mit verschiedenen Elementen von wxwidget.
Alles in allem also etwas das für crossplattform Sachen sicher nicht schlecht ist, aber für GNU/Linux bzw. gnome/gtk auch alles andere als optimal ist. Daher war es für mich nie wirklich interessant.



Zeichnet GTK unter Windows selbst? Oder werden hier die Windows Libs genutzt? Läuft GTK unter Windows denn stabil? Hab da oft nichts positives gehört.


gute Frage. Also ich habe es nie selber unter windows versucht.
Was ich weiß:
Lange Zeit haben Gtk Anwendungen auch unter windows den default gtk style verwendet, haben also etwas fremd ausgesehen. Seit gtk2.4 übernimmt gtk aber relativ gut die windows styles (afaik ab win2000) und in gtk2.6 wurde es afaik weiter verbessert.
Alles in allem sollte es kein Problem sein gtk unter windows zu nutzen, es gibt ja auch kommerzielle Firmen die gtk für windows verwenden.



Allerdings sehe ich, wie schon gesagt noch den Vorteil von Qt, dass ich nur eine einzige Abhängigkeit habe und kein Baukastenprinzip.


sicher hat es auch seine Vorteile, wollte ich auch nie bestreiten.
Mich stört nur, dass Qt auch da Eigenwege geht, wo es eigentlich nicht nötig gewesen wäre und wo man sich einfach besser an der Programmiersprache ihrer Wahl (C++) halten hätten können bzw. sollen.

miketech
09.01.2005, 01:39
Hi,


GTK ist in C geschrieben, soweit richtig. Aber gtkmm ist nicht der "objektorientierten Ansatz" sondern die C++ Bindings für gtk+. gtkmm macht also nicht mehr als das es dir ermöglich Gtk+ in C++ auf die C++ typische Art zu verwenden.

Ok danke.


Mal aus persönlichem Interesse: Bist Du Gnome-User? Oder XFCE oder so?


MySQL setzt ja z.B. auch auf GTK, was die Anwendungen mit GUIs betrifft. Wobei ich eher glaube, dass hier versucht wird auf Lizenzkosten von Qt zu verzichten, die ja nun nicht so günstig sind.

Ich werde mich mal erkundigen, wie GTK-Programme unter Windows laufen. Gimp läuft ja wohl, aber ich habe wie gesagt von schon so einigen crashes gehört.

Gruß

Mike

cocaxx
09.01.2005, 12:02
Hi!

Das größte Problem mit gtk unter Windows ist, dass die user zu dumm sind, gtk zu installieren. Drauf ist es nämlich nicht und sie sind es auch nicht gewohnt, irgendwelche Abhängigkeiten selber zu installieren.
Da ist es bequemer, sie ziehen sich Photoshop per KaZaa und cracken es, das sind sie gewohnt....


grüße
cocaxx

miketech
09.01.2005, 12:03
Der war böse ;))

Mike

manthano
09.01.2005, 12:08
Aber wahr. Ist wirklich so, alle Windows-User die ich kenne sind zu faul ein bisschen Software zu installieren oder mal selbst ein Problem in die Hand zu nehmen, denken aber sie wären besonders genial wenn sie sich kommerzielle Programme illegal runterladen. X(

Sir Auron
09.01.2005, 12:13
Hi!

Das größte Problem mit gtk unter Windows ist, dass die user zu dumm sind, gtk zu installieren. Drauf ist es nämlich nicht und sie sind es auch nicht gewohnt, irgendwelche Abhängigkeiten selber zu installieren.
Da ist es bequemer, sie ziehen sich Photoshop per KaZaa und cracken es, das sind sie gewohnt....


grüße
cocaxx
Tja dann hat man zwar das minderwertigere Programm, aber es geht ja schnell :) .

Nee mal im Ernst GTK auf Windows wird echt wenig benutzt (außer static bilds). Schade.

miketech
09.01.2005, 12:15
Hi,

naja aber Qt-Programme seh ich dort auch sehr selten. Die meisten kommerziellen Programme werden ja noch ausschließlich für Windows entwickelt. Da tuns dann auch die Windows Libraries. D.h. da wird dann mit MFC oder wie das alles heißt rumgefriemelt, bis es schließlich mal läuft *scnr*

Mike

pinky
09.01.2005, 13:07
Mal aus persönlichem Interesse: Bist Du Gnome-User? Oder XFCE oder so?


ich lasse mich da ungern in Kategorien drängen. Auf dem Desktop verwende ich hauptsächlich gnome, habe aber auch kde installiert und verwende auch das ab und zu. Auf dem Notebook verwende ich zur Zeit xfce, da es die richtige Mischung zwischen klein und konfortabel hat. Habe aber auch schon fluxbox, windowmaker und ähnliches verwendet und es ist auch nicht ausgeschlossen das ich das mal wieder verwenden.
Ich lege mich da nur ungerne fest, warum auch...
Aber alles in allem bin ich schon eher auf der gtk/gnome Schiene, sind für mich einfach oft die besseren Programme.



Nee mal im Ernst GTK auf Windows wird echt wenig benutzt (außer static bilds). Schade.


Naja, ein aktuelles Beispiel wäre http://www.multidmedia.com/ die ihre komplette windows Software mit Gtk erstellen, wobei sie gerade negativ auffallen weil sie wahrscheinlich die GPL verletzen, da sie die gnome-stock-icons verwenden.

Ansonmsten gibt es hier ja auch noch ein paar, die Listen sind aber sicher alles andere als vollständig:
http://www.gtkmm.org/commercial_support.shtml
http://www.gtk.org/success/

Ich denke da gibt es auf jedenfall keinen großen Unterschied zu Qt.

miketech
09.01.2005, 15:16
Hi,

ok ein Allround-User. Ich muss mich immer erst auf ein Desktop-System einarbeiten, damit all meine Anwendungen genau so sind, wie ichs möchte und alles so ausschaut und sich anfühlt, damit ich mich wohl fühle. Derzeit grad am Gnome rumprobieren. Da muss ich der Fairness halber noch zugeben, dass es im Moment gar nicht so schlecht aussieht. Nur mit den Icons kämpfe ich noch etwas. Die sind alle braun und wenn ich andere installiere, werden nie alle Icons mit abgedeckt. Gibt immer wieder welche, die noch braun/grau sind. Sobald XFCE in der Version 4.2 erschienen ist, was ja bald der Fall sein dürfte, werde ich damit weitertesten. XFCE 4 unterstützt bisher bei mir kein Xinerama. Ich hab hier zwei Bildschirme gleichzeitig laufen und XFCE läuft nur auf einem, obwohl auf der XFCE Seite steht:

Xfce 4 features and components
Real multiscreen and Xinerama support.

Vielleicht bezieht sich das erst auf Version 4.2, mal schauen.


Programmiert hier eigentlich auch jemand mit TCL/Tk? Oder anderen Toolkits wie FOX, oder was es alles so gibt? Bis jetzt wurden hier ja nur die größten, GTK und Qt angesprochen.

Gruß

Mike

hehejo
16.02.2005, 14:51
Ich hab in letzer Zeit wieder etwas Lust auf Python bekommen.
Darum hatte ich mich auch mal an wxPython (http://www.wxpython.org/ (Pythonbindings für wxWidgets) rangemacht.
Das finde ich im Moment recht einfach zum programmieren - aber sicherlich werde ich mir auch mal pygtk (www.pygtk.org) ansehen.
Falls sich pyGtk so schön wie das wxPython anfühlt - ok ich hab bisher nur sehr kurz "gefühl" - dann ist klar gtk mein Favourit!

@gtk auf Windows:
Ich hab hier gimp 2.0 installiert.
Auf der entsprechenden Seite waren auch noch die Downloads für GTK_for_Windows. Einfach installiert und *tattaa*.


@Bindings für verschiedene Sprachen
Wie macht man denn sowas???

miketech
16.02.2005, 15:01
Hi,

rein Interesse halber: Hat jemand mal Erfahrungen mit Python + Qt gemacht? Ich höre oft nur Python in Verbindung mit Gtk. Davon schwärmen doch einige. Nicht, dass ich vorhätte mich damit zu beschäftigen, nur hör ich davon sehr wenig.

Wenn auf Windows Gtk installiert, kann man dann einfach die PyGtk - Programme ausführen? Oder gibts da noch mehr zu tun, bis sowas läuft?

Zu den Sprachbindings: Das würde mich auch mal sehr interessieren. Wie geht man da vor?

Gruß

Mike

hehejo
16.02.2005, 15:25
Ich glaube, es muss auch noch pygtk installiert werden.

edit: DANKE

hehejo
19.02.2005, 17:12
So. ich hab mich etz ein bisschen mit GTK+ (also pyGTK) beschäftigt!
Ich bin restlos begeistert! Das Grafikzeugs geht einem echt einfach von der Hand. Hat man einmal das Grundprinzip verstanden dann rockt die Bude!
Wenn ich da an die MFC denke, wird mir richtig schlecht!
Ob ich nun gtkmm oder pygtk verwende.. EGAL. Die Logik dahiner ist gleich!

GTK!!