PyGTK immer seltener genutzt?

[burli]

Vielleicht bilde ich mir das nur ein, aber in den letzten Monaten bin ich der Meinung, im PyGTK Forum werden immer seltener Fragen gestellt. Wird das jetzt mehr und mehr durch PyQt ersetzt?

[Hyperion]

Vielleicht bilde ich mir das nur ein, aber in den letzten Monaten bin ich der Meinung, im PyGTK Forum werden immer seltener Fragen gestellt. Wird das jetzt mehr und mehr durch PyQt ersetzt?

Hältst Du dieses Forum für empirisch wirklich repräsentativ? Ich habe eher das Gefühl, dass in letzter Zeit mehr Fragen zu Tk gestellt werden. Aber ich würde hier keinen Trend ableiten wollen

[numerix]

Über den möglichen Zusammenhang zwischen dem Betrieb im jeweiligen Unterforum und der Verbreitung des jeweiligen GUI-Toolkits gab es schonmal einen Thread. Meiner Erinnerung nach (die ist aber recht blass) wurde schon damals festgestellt, dass im Tkinter-Forum nicht gerade wenig los ist, aber das nicht unbedingt mit der stärkeren Verbreitung zu tun haben muss.

M.E. liegt das in erster Linie daran, dass Tkinter in vielen Fällen zu den "batteries included" zählt (oder gezählt wird - die Diskussion möchte ich jetzt nicht erneut aufleben lassen) und für viele GUI-Einsteiger zunächst einmal die erste Wahl ist. Da das in nicht wenigen Fällen auch Programmieranfänger sind, geht es im Tkinter-Subforum häufig (allerdings nicht nur) um Grundlegendes - da meldet sich so manch einer zu Wort, der zweifelsfrei zu früh mit der GUI-Programmierung begonnen hat. Ich vermute mal, dass das bei PyQt und PyGTK seltener vorkommt.

[burli]

Nein, repräsentativ für den weltweiten Anteil sicher nicht. Ich hab einfach nur den Eindruck, dass verglichen mit Tk und Qt nur noch wenige GTK Fragen gestellt werden. Kann mich aber auch irren

[DasIch]

Ich denke eher dass erfahrenere Programmierer dazu tendieren gleich C++ bzw. C, C# oder Vala zu nutzen, das ist deutlich angenehmer und man kann immernoch recht problemlos auf Python zurueck greifen.

[burli]

Ich wundere mich nur, dass es zu PyGTK in letzter Zeit relativ wenig Fragen gestellt werden, und das ausgerechnet da, wo ich anfange mich mit PyGTK zu befassen.

[lunar]

@DasIch: Du glaubst wirklich, dass jemand C++ oder gar C anstelle von Python benutzt, wenn er die Wahl hat (sprich beide Sprachen kennt und keinen Beschränkungen unterworfen ist)?

[burli]

Ich möchte hier jetzt keinen Glaubenskrieg über Sprachen oder grafische Toolkits vom Zaun brechen. Die gab es zur Genüge und noch keiner hat zum Ziel geführt.

Mich interessiert mehr die Verteilung der Toolkits.

[Xynon1]

Ich würde mal einfach sagen, welcher ein KDE System hat, wird eher zu QT kommen, als zu GTK, und umgekehrt.
Wobei ich nicht sagen möchte das es sich ausschließt das man auch mit dem anderen unter dem System gearbeitet wird.

Und ich stimme numerix vollkommen zu, die meisten Anfänger fange bei den GUI Toolkits immer mit Tkinter an, weil auch viele Tutorien und einige Bücher dazu gibt, die extra für Anfänger sind.
Zu dem finde ich GTK nun nicht sonderlich "anders" als Tk, was zur Folge hat, dass wenn jemand mit Tk Anfängt und dieses Toolkit einem nicht mehr ausreicht, ist GTK eine gute Wahl um sofort zu wechseln.
Wogegen mir aufgefallen ist, das Umsteiger von .NET oder MFC Anwendungen eher gleich zu QT wechseln.

So habe ich es zumindest beobachtet, andere können sicher zu einem anderen Schluß gekommen sein.
Aber die Verteilung davon, lässt sich wohl kaum absehen.

[burli]

Naja, ganz freiwillig nutze ich GTK nicht. Ich möchte einen Editor etwas erweitern und am geeignetsten hat sich bisher Gedit erwiesen. Habe bisher jedenfalls noch keinen besseren dafür gefunden

[DasIch]

@DasIch: Du glaubst wirklich, dass jemand C++ oder gar C anstelle von Python benutzt, wenn er die Wahl hat (sprich beide Sprachen kennt und keinen Beschränkungen unterworfen ist)?

Bei einer guten API muss ich nicht umdenken zwischen dem was in der entsprechenden Sprache gutes Design ist und wie es statt dessen implementiert wurde. Sowohl bei Qt als auch bei GTK verletzen die Python Bindings einen Grossteil der Regeln die ich implizit fuer gutes API Design in Python gegeben sehe und verhalten sich erstmal wider meinen Erwartungen.

Wenn ich Qt in C++ bzw. GTK in C oder Vala anspreche ist dies nicht der Fall, dort entsprechen die APIs den Erwartungen die man an eine API hat und man macht sich weit weniger Gedanken ueber die API und dementsprechend mehr ueber die Anwendung selbst.

Wenn es an die Logik geht funktioniert dass ganze zwar nicht mehr und wenn man ohnehin schon Erfahrung indem Bereich hat ist dies sicherlich ebenfalls kein nennenswertes Argument mehr aber trotzdem ist dies fuer mich genug um eine andere Sprache fuers Frontend in Erwaegung zu ziehen und eventuell auch zu nutzen.

Dazu kommt das erfahrungsgemaess Python Bindings haeufig schlecht wenn ueberhaupt dokumentiert sind. Im Falle von Qt kein Problem da man dort groesstenteils auf C++ Doku zurueckgreifen kann dass beweist aber noch eher das urspruengliche Argument. Die GTK Doku zu den Python Bindings ist vergleichsweise gut aber auch nur API Dokumentation.

[derdon]

Naja, ganz freiwillig nutze ich GTK nicht. Ich möchte einen Editor etwas erweitern und am geeignetsten hat sich bisher Gedit erwiesen. Habe bisher jedenfalls noch keinen besseren dafür gefunden

Ist zwar auch GTK, kannst aber trotzdem mal einen Blick auf PIDA werfen

[burli]

Ist zwar auch GTK, kannst aber trotzdem mal einen Blick auf PIDA werfen

Ist afaik zu Python lastig und nutzt vi oder emacs als Editor Komponente (korrigier mich, wenn ich mich irre). Es geht aber um C Programmierung und soll auch Einsteigerfreundlich sein. Gedit ist da recht angenehm und einfach.

[lunar]

@DasIch: Wenn Du Deine *eigene* Meinung vertrittst, dann äußere auch Deine eigene Meinung, aber spricht nicht für alle „erfahrenen Programmierer“. Ich weiß nicht, was Du unter den „Regeln für gutes API-Design“ verstehst, und welche Deiner „Erwartungen“ an das Toolkit widerlegt wurden, doch ich weiß auch nicht, ob Du überhaupt je Qt-Anwendungen in C++ und Python geschrieben hast und somit überhaupt selbst zu diesen „erfahrenen Programmieren“ zählen kannst.

Ich habe Qt-Anwendungen in beiden Sprachen geschrieben, und würde Python jederzeit vorziehen. Natürlich ist die Anbindung nicht perfekt, und hat wie jede andere Bibliothek auch Ecken und Kanten, nur sind das alles Trivialitäten angesichts der ungeheuren Komplexität und verhältnismäßig geringen Ausdrucksstärke von C++ gegenüber Python. Davon abgesehen sind das oft Python-spezifische Idiome: Es ist unschön, dass die Python-Anbindungen Qt-Eigenschaften nicht als Python-Eigenschaften repräsentiert. Ja und? C++ hat schlicht gar keine Eigenschaften. "QObject::property()" ist kein echter Ersatz, insbesondere sind Qt-Eigenschaften über diese API nicht typsicher.

Wenn PyGtk gegenwärtig gegenüber PyQt tatsächlich verliert (was ich stark bezweifele), dann eher, weil Qt mit der Übernahme durch Nokia freier geworden ist, und zudem eine rege Weiterentwicklung mit interessanten neuen Funktionen erfährt. In vielem ist Qt Gtk mittlerweile voraus, es ist umfangreicher, unabhängiger von der konkreten Plattform, und hat einige interessante und mächtige APIs ohne Entsprechung in Gtk (e.g. QML). Außerdem hat Qt dank der Unterstützung durch Nokia gerade auf Mobilplattformen mittlerweile eine große Reichweite.

[noisefloor]

Hallo,

@burli: Es kommt ja auch drauf an, ob du für einen bestimmten Zweck und eine bestimmte Distro brauchst. Bei dir tippe ich mal auf Ubuntu . Und unter Ubuntu ist Python + GTK sehr gängig.

Wenn du was mit Python + GTK für Ubuntu entwickeln möchtest: Quickly ist ein interessanter Ansatz.

Gruß, noisefloor

[snafu]

Dazu kommt das erfahrungsgemaess Python Bindings haeufig schlecht wenn ueberhaupt dokumentiert sind. Im Falle von Qt kein Problem da man dort groesstenteils auf C++ Doku zurueckgreifen kann dass beweist aber noch eher das urspruengliche Argument. Die GTK Doku zu den Python Bindings ist vergleichsweise gut aber auch nur API Dokumentation.

Da übertrage ich doch lieber ein C-Tutorial gedanklich auf Python-Funktionen als dass ich deshalb komplett umsatteln würde und mein Programm in einer unbequemen Sprache designen muss. So mache ich mir IMHO ohne Not das Leben schwer. Und mal ganz im Ernst: Bei der ausführlichen Namensgebung, die von den meisten "objektorientierten" C-Bibliotheken so verwendet wird, ist es nun wirklich nicht so schwer herauszufinden, wie wohl der Klassenname in Python lauten könnte. Und ein *erfahrener Python-Programmierer* (scnr) sollte schnell drauf kommen, dass das erste Argument sowas ähnliches wie `self` ist. ;P

Zu Vala: Es mag eine gute Idee für GObject-basierte Bibliotheken sein, so dass man es logischerweise auch mit Gtk benutzen kann. Allerdings greift dort deine Argumentation nicht mehr. Mir sind bisher jedenfalls nicht so viele auf Vala bezogene Gtk-Tutorials untergekommen. Zumindest unter Garantie nicht mehr als welche, die in Python geschrieben wurden.