GUI Programmierung: Toolkit vergleich

Dieses Thema im Forum "Programmieren allgemein" wurde erstellt von pinky, 01.01.2005.

  1. #1 pinky, 01.01.2005
    Zuletzt bearbeitet: 01.01.2005
    pinky

    pinky König

    Dabei seit:
    11.08.2004
    Beiträge:
    795
    Zustimmungen:
    0
    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.
     
  2. Anzeige

    Schau dir mal diesen Ratgeber an. Viele Antworten inkl. passender Shell-Befehle!
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. #2 Sir Auron, 01.01.2005
    Sir Auron

    Sir Auron Routinier

    Dabei seit:
    26.04.2004
    Beiträge:
    482
    Zustimmungen:
    0
    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++.
     
  4. pinky

    pinky König

    Dabei seit:
    11.08.2004
    Beiträge:
    795
    Zustimmungen:
    0
    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.

    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.

    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.

    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
     
  5. oenone

    oenone Freier Programmierer[Mod]

    Dabei seit:
    22.08.2002
    Beiträge:
    599
    Zustimmungen:
    0
    Ort:
    Mannheim
  6. pinky

    pinky König

    Dabei seit:
    11.08.2004
    Beiträge:
    795
    Zustimmungen:
    0
    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?
     
  7. #6 Sir Auron, 01.01.2005
    Sir Auron

    Sir Auron Routinier

    Dabei seit:
    26.04.2004
    Beiträge:
    482
    Zustimmungen:
    0
    Das Buch ist ja recht teuer, naja mal gucken, ob ich es mir besorge.
     
  8. #7 avaurus, 01.01.2005
    avaurus

    avaurus °°°°°°°°°°°°°

    Dabei seit:
    28.12.2003
    Beiträge:
    965
    Zustimmungen:
    0
    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).
     
  9. #8 MrFenix, 01.01.2005
    MrFenix

    MrFenix Executor

    Dabei seit:
    16.10.2004
    Beiträge:
    480
    Zustimmungen:
    0
    Ort:
    Siegen, NRW
    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...
     
  10. pinky

    pinky König

    Dabei seit:
    11.08.2004
    Beiträge:
    795
    Zustimmungen:
    0
    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#)

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

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

    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).
     
  11. #10 pinky, 01.01.2005
    Zuletzt bearbeitet: 01.01.2005
    pinky

    pinky König

    Dabei seit:
    11.08.2004
    Beiträge:
    795
    Zustimmungen:
    0
    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
     
  12. #11 Sir Auron, 01.01.2005
    Sir Auron

    Sir Auron Routinier

    Dabei seit:
    26.04.2004
    Beiträge:
    482
    Zustimmungen:
    0
    Ist ja ganz nett, werd es mir kaufen wenn ich Kernel Architektur komplett gelesen und verstanden habe.
     
  13. oenone

    oenone Freier Programmierer[Mod]

    Dabei seit:
    22.08.2002
    Beiträge:
    599
    Zustimmungen:
    0
    Ort:
    Mannheim
    hm... soo arg hab ich mich noch nicht mit GUI programmierung beschäftigt.. aber bisher war ich positiv davon überrascht.

    auf bald
    oenone
     
  14. #13 avaurus, 01.01.2005
    avaurus

    avaurus °°°°°°°°°°°°°

    Dabei seit:
    28.12.2003
    Beiträge:
    965
    Zustimmungen:
    0
    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.
     
  15. Anzeige

    Vielleicht findest du HIER Antworten.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  16. #14 pinky, 02.01.2005
    Zuletzt bearbeitet: 02.01.2005
    pinky

    pinky König

    Dabei seit:
    11.08.2004
    Beiträge:
    795
    Zustimmungen:
    0
    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).
     
  17. #15 thorus, 02.01.2005
    Zuletzt bearbeitet: 02.01.2005
    thorus

    thorus GNU-Freiheitskämpfer

    Dabei seit:
    03.11.2002
    Beiträge:
    757
    Zustimmungen:
    0
    Ort:
    Passau, Niederbayern
    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()).

    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.
     
Thema:

GUI Programmierung: Toolkit vergleich

Die Seite wird geladen...

GUI Programmierung: Toolkit vergleich - Ähnliche Themen

  1. Dart 1.9 erleichtert asynchrone Programmierung

    Dart 1.9 erleichtert asynchrone Programmierung: Google hat eine neue Version der für das Web optimierten Programmiersprache Dart veröffentlicht. In Dart 1.9 fügten die Entwickler des in...
  2. Einstieg in die QT-Programmierung

    Einstieg in die QT-Programmierung: Hallo, ich würde gerne in die QT-Programmierung einsteigen mit dem Ziel, grafische Programme mit C#/C++ für KDE zu schreiben (bestmögliche...
  3. kernel Programmierung sys_creat

    kernel Programmierung sys_creat: Hallo zusammen Kurz zu meiner Person Mein Name ist Andre, ich bin 27 und bin eigentlich Aquarianer :) Ich arbeite mich grade ein wenig in...
  4. Neuling braucht Hilfe bei Shellprogrammierung

    Neuling braucht Hilfe bei Shellprogrammierung: hey wollte mich in die Umgebung Shellskripte einarbeiten mein erstes Hindernis ist folgende Aufgabe: Ich soll ein einfaches Shellskript...
  5. DVB-T Programmierung

    DVB-T Programmierung: Hallo Leute. Ich will ein zum "Rumspielen" ein Programm schreiben, mit dem ich mir die Empfangsstärke einer DVB- Karte anzeigen lassen...