Warum hat GTK+ so einen schlechten Ruf?

Qt wird von vielen gelobt und GTK+ gehaßt.

Hat das irgendwelche handfesten Gründe?

Was spricht gegen die Verwendung von GTK+ 3.0 für neue Projekte?

Oberon_0

Es sieht auf z.B. auf Windows nicht nativ aus.

Unter KDE sieht es auch nicht nativ aus.

Oberon_0 schrieb:

Es sieht auf z.B. auf Windows nicht nativ aus.

Das tut Qt aber auch nicht.

Außerdem ist das nebensächlich, da das nur Designer betrifft.
Mich würde interessieren, warum GTK+ aus Software Entwickler und Programmierersicht so unattraktiv ist.

Wie das unter XY dann aussieht, ist für die Frage also völlig irrelevant, mal ganz davon abgesehen, daß sowohl Qt als auch GTK+ Theming fähig sind.

player424

Also für mich ist es nicht attraktiv weil es sich nicht statisch linken lässt, was für mich unter Windows wichtig ist.

Dravere

Wer hasst denn GTK? Ist mir ganz was neues, normalerweise wird die Bibliothek für ihren Aufbau doch eher gelobt.
Mir sind grundsätzlich nur zwei Kritikpunkte bei GTK unter Windows bekannt:
1. Unter Windows kein native Look.
2. Zu viele einzelne Bibliotheken, wodurch man ein ganzes Arsenal an DLLs mit der Anwendung ausliefern muss.

Grüssli

Artchi

1. C API (ja, für mich als C++'ler ist es ein Contra-Argument. Für C'ler sieht es
natürlich anders aus)

2. ohne System-abhängige Tools (genau gesagt Linux-Tools) unmöglich selbst zu bauen und linken. Weil ein Rattenschwanz an Libs/DLLs

3. kein natives Look & Feel unter Windows (nein, nachgemacht ist immer noch nicht original)

4. warum gibt es bei GIMP unter Windows Redraw-Fehler? (unter anderen GTK-Anwendungen unter Windows sicherlich auch)

Was aber Qt in dem Vergleich zu suchen hat, ist mir allerdings auch schleierhaft? Wenn dann muß man doch Qt mit gtkmm vergleichen! Und dann fällt für viele sicherlich schon mal das Contra-Argument "C API" weg. gtkmm ist aus C++-Programmierersicht schon ganz anders.

player424 schrieb:

Also für mich ist es nicht attraktiv weil es sich nicht statisch linken lässt, was für mich unter Windows wichtig ist.

Und warum willst du statisch linken?
Beim dynamischen Linken kann man die Lib wenigstens austauschen, falls die alte eine Sicherheitslücke hat. Das ist ein Grund, warum die LGPL statisches Linken verbietet.

[quote=Dravere]
Wer hasst denn GTK? Ist mir ganz was neues, normalerweise wird die Bibliothek für ihren Aufbau doch eher gelobt.[/quote]

Die meisten werben für Qt wenn GTK+ das Thema ist.
Das spricht IMO eigentlich schon Bände dafür.

Irgendeinen Grund muß es ja geben und die Typen sind sicher nicht alle von Nokia bezahlt.

[quote=Artchi]
1. C API (ja, für mich als C++'ler ist es ein Contra-Argument. Für C'ler sieht es natürlich anders aus)
[/QUOTE]

Dafür gibt's doch gtkmm.

Wenn dann muß man doch Qt mit gtkmm vergleichen! Und dann fällt für viele sicherlich schon mal das Contra-Argument "C API" weg. gtkmm ist aus C++-Programmierersicht schon ganz anders.

Wenn ich GTK+ meine, dann schließe ich damit natürlich alle Sprachbindings zu GTK+ mit ein.
Ich betrachte GTK+ von gtkmm also nicht als losgelöst, sondern als ein Bestandteil von diesem. Ein Bestandteil für C++ Entwickler halt.

Artchi

Viele finden das Framework Qt toll. Also nicht den GUI-Part von Qt, sondern das Gesamtpaket. Sie wissen halt nicht, das es die Std-Lib, Boost, POCO usw. gibt. Also nimmt man Qt und fertig.

Aber die anderen Nachteile bleiben trotzdem... wie z.B. keine nativen Controls (und nein, Qt zeichnet die Dinger auch nur nach). Und was ist mit meinen anderen aufgeführten Punkten?

Dravere

Gimp Toolkit schrieb:

Die meisten werben für Qt wenn GTK+ das Thema ist.
Das spricht IMO eigentlich schon Bände dafür.

Irgendeinen Grund muß es ja geben und die Typen sind sicher nicht alle von Nokia bezahlt.

1. Wieso soll dies nun heissen, dass sie GTK hassen? Wenn jemand Qt bevorzugt, muss GTK ja nicht gleich hassen.
2. Fanboys sind kein Argument bei der Auswahl von Bibliotheken. Wenn das Thema GTK ist und jemand Qt vorschlägt, weil dort doch alles viel einfacher und schöner ist, dann ist er ein Fanboy und kann getrost ignoriert werden.
3. Qt ist wahrscheinlich einfach auch bekannter, weshalb es mehr Leute einsetzen. Ich denke vor allem bei Anfängern wird man oft Qt finden. Qt kommt als sorglos Paket daher, mit eigener IDE, ist ein ganzes Framework, usw. usf. Ein Anfänger, welcher unbedingt mal ein paar schöne GUIs machen möchte, kann dies mit Qt sehr schnell realisieren. Ob der Code gut oder schlecht ist, sei mal dahingestellt. Und diese Anfänger bleiben dann bei Qt, weil sie so gut wie alles dort haben, was sie benötigen oder zumindest glauben sie das. Sie sind zufrieden und schauen daher auch nicht über den Tellerrand. Und die schlimmen entwickeln sich dann zu Fanboys.

Grüssli

Artchi schrieb:

Und was ist mit meinen anderen aufgeführten Punkten?

Die habe ich alle gelesen, ich widerspreche diesen auch nicht, denn sonst würde ich etwas zu diesen schreiben.

rüdiger

Ein großes Problem von GTK war die Portabilität. Windows: Kein native Look und schwierig einzurichten (wobei wenn man hier im Forum schaut, dann scheinen Entwickler unter Windows eh Schwierigkeiten zu haben, sobald sie eine fremde Bibliothek einbinden wollen :)). Mac OS X: Nur über X11 benutzbar und komplett fremder Look. Das hat sich wohl mittlerweile gebessert. Vorallem gibt es wohl ein GTK+ das native auf Aqua (OSX) läuft.

dv_

Die Dokumentation von Qt ist in weiten Teilen deutlich besser, dasselbe gilt für die API. Natürlich gibt es auch Schwachstellen, jedoch überwiegen - für mich zumindest - die Vorteile.

Ein paar Punkte, die mir gerade einfallen:

GTK hat kein Äquivalent zu QGraphicsView, und Clutter ist auch kein Ersatz
wo hat GTK sowas wie QML?
die Webkitintegration ist ziemlich einfach zu verwenden - ne Webseite ist mit 1-2 Zeilen eingebaut, und zwar mit voll funktionsfähigem Webkit
GTK hat nichts, was an Qt Designer rankommt (Glade ist ein Witz dagegen)
Qt ist das einzige mir bekannte Toolkit, welches Codegenerierung richtig macht. Die meisten RAD-Umgebungen erzeugen ein komplettes Programm; als Programmierer bleiben einem nur sehr eingeschränkte Möglichkeiten, irgendwo eigenen Code einzufügen. Wehe, man weicht von der vorgegebenen Struktur ab. Bei Qt ists andersrum: der erzeugte Code ist eine Klasse mit einer Funktion setupUi(), welches ein Parentwidget mit dem Interface befüllt. Der Programmierer selbst entscheidet, wo das getan wird in seinem Code. Beispielcode:

QWidget *parent = new QWidget;
generated_gui.setupUi(parent);
parent->show();

darüberhinaus ist das optional; mit der QtUiTools-Library (ist bei Qt dabei) kann man das UI auch direkt von einer XML-UI-Beschreibung (die .ui Files) generieren lassen

das MVC-System ist um vieles einfacher und intuitiver, es ist bei weitem nicht perfekt, aber das GTK-System ist hoffnungslos kompliziert
portiert mal GTK 2 auf eine Plattform ohne X11 - mit Qt geht das rel. einfach, teils wegen des Designs, teils da dokumentiert ist, was man machen muss

Mit GTK 3 hat sich einiges gebessert, u.a. ist es nicht länger von X11 abhängig. Stattdessen von Cairo. Das ist der Wermutstropfen; Cairo ist lahm. Antigrain schlägt Cairo zehntausendfach bei Performance und Bildqualität... aber es ist eben C++.

dv_ schrieb:

wo hat GTK sowas wie QML?

Ist die neue theming API von GTK+ 3.0, die so etwas wie CSS nutzt, mit QML vergleichbar?

* A new theming API which sports a familiar CSS syntax for theme
configuration and other improvements such as animated state
transitions.
http://mail.gnome.org/archives/gnome-announce-list/2011-February/msg00022.html

[*] portiert mal GTK 2 auf eine Plattform ohne X11 - mit Qt geht das rel. einfach, teils wegen des Designs, teils da dokumentiert ist, was man machen muss

Naja, in Qt 1.0 entwickelt man heutzutage ja auch nicht mehr.
Wer neue Projekte startet, der wird wohl GTK 3 nehmen.

Das ist der Wermutstropfen; Cairo ist lahm. Antigrain schlägt Cairo zehntausendfach bei Performance und Bildqualität... aber es ist eben C++.

Antigrain kostet für kommerzielle Projekte Geld.
Aktuelle Versionen stehen unter der GPL Lizenz.
http://www.antigrain.com/license/index.html#PAGE_LICENSE

Cairo steht dagegen unter der LGPL bzw. Mozilla Public License

dv_

Gimp Toolkit schrieb:

Ist die neue theming API von GTK+ 3.0, die so etwas wie CSS nutzt, mit QML vergleichbar?

* A new theming API which sports a familiar CSS syntax for theme
configuration and other improvements such as animated state
transitions.
http://mail.gnome.org/archives/gnome-announce-list/2011-February/msg00022.html

Nein. Erstens hat Qt schon seit langem CSS-artiges Styling, zweitens ist QML etwas völlig anderes. Es ist am ehesten mit XUL, XAML vergleichbar.

Naja, in Qt 1.0 entwickelt man heutzutage ja auch nicht mehr.
Wer neue Projekte startet, der wird wohl GTK 3 nehmen.

Naja, das ist taufrisch, ich denke, man muss noch GTK 2 als Maß nehmen. In ein paar Monaten siehts wohl anders aus, da es dann auch in den ganzen Repositories usw ist.

Antigrain kostet für kommerzielle Projekte Geld.
Aktuelle Versionen stehen unter der GPL Lizenz.
http://www.antigrain.com/license/index.html#PAGE_LICENSE

Cairo steht dagegen unter der LGPL bzw. Mozilla Public License

Du übersiehst da was. Antigrain 2.5 ist GPLed. Antigrain 2.4 steht unter der BSD. Der einzige relevante Unterschied ist ein Polygonclipper-Code, der zu Antigrain dazugekommen ist, und unter der GPL steht. Die meisten Leute verwenden die Version 2.4.

Ben04

dv_ schrieb:

Du übersiehst da was. Antigrain 2.5 ist GPLed. Antigrain 2.4 steht unter der BSD. Der einzige relevante Unterschied ist ein Polygonclipper-Code, der zu Antigrain dazugekommen ist, und unter der GPL steht. Die meisten Leute verwenden die Version 2.4.

Das Hauptargument gegen Antigrain war so weit ich weiß, dass es nicht mehr wirklich weiterentwickelt wird. Du selbst empfiehlst eine veraltete Version zu verwenden. Darauf ein Toolkit aufzubauen, dass mehrere Jahre lang verwendet und weiterentwickelt werden soll wäre äußerst leichtsinnig.

rüdiger

Ben04 schrieb:

dv_ schrieb:

Du übersiehst da was. Antigrain 2.5 ist GPLed. Antigrain 2.4 steht unter der BSD. Der einzige relevante Unterschied ist ein Polygonclipper-Code, der zu Antigrain dazugekommen ist, und unter der GPL steht. Die meisten Leute verwenden die Version 2.4.

Das Hauptargument gegen Antigrain war so weit ich weiß, dass es nicht mehr wirklich weiterentwickelt wird. Du selbst empfiehlst eine veraltete Version zu verwenden. Darauf ein Toolkit aufzubauen, dass mehrere Jahre lang verwendet und weiterentwickelt werden wäre äußerst leichtsinnig.

Cairo ist doch eine Eigenentwicklung der GTK-Leute. Da hätte man auch AGG nehmen können. (btw. gab es nicht einen AGG 2.4 Fork?)