Erfahrungen und Meinungen zu Python GUI-Toolkits gewünscht

[PmanX]

Hallo,

auf der Suche nach einem geeigneten GUI-Toolkit würde ich gern Eure Meinungen hören.
Mit meiner bisherige Sachkenntnis tendiere zu Pygtk, Glade und Tepache als code sketcher,
da ich dort das größte know-how vermute.
WxPython ist sicher auch interessant, IMHO etwas überladen und weniger ausgereift.

Gruß P.

[oliver1974]

Inwiefern empfandest du wxPython als überladen?
Ich fand pyGTK eher als teilweise.. ähmmm.. seltsam.. Insbesondere was TreeViews und dergleichen anging... zwar leistungsfähiges Modell, aber so von der Sorte "Theoretisch tolles Konzept.. Aber ich will doch nur mal eben einen TreeView haben!!!"

wxPython fand/finde ich da pragmatischer, da sind viele Sachen einfach schon so in funktionsfähigen Zustand, wie sie für mich sein sollen.
Ehrlich gesagt, kam ich noch mit keinem Gui-Toolkit auf Anhieb so gut zurecht, und da zähle ich jetzt auch mal SWING und SWT aus dem Java-Umfeld mit rein.

Klar hat wxPython Macken... Alleine schon die Schreibweise der Methoden beißt sich total mit dem, was in Python üblich ist... und seitdem man nicht mehr zwingend auf die IDs angewiesen ist, schleppt man in allen Methoden beim ID Parameter immer ein "-1" oder wx.ID_ANY mit rum (wenn ich das richtig verstanden haben..), aber das hebelt die Vorteile für mich nicht aus.

Auch haben die in der Vergangenheit ihre API doch mal etwas geändert, was zur Folge hat, dass manche Tutorials immer noch auf der alten API basieren.. die oft sogar noch gehen, aber einfach nicht mehr der eleganteste Weg sind, wie man heute mit wxPython arbeiten würde.

Empfehlenswert ist da ergänzende Literatur.. In dem Fall mal klassisch gedruckt, "wxPython in Action" von Rappin/Dunn fand ich sehr praktisch.. nein, ich bin an dem Verlag nicht beteiligt.

[gerold]

IMHO etwas überladen und weniger ausgereift.

Hallo PmanX!

Das empfinde ich nicht so. wxPython hat in den letzten Jahren einen großen Schritt in Richtung Programmierfreundlichkeit getan.

mfg
Gerold

[sape]

@Oliver und Gerold:
Dito.

Zu dem bisher gesagten will ich noch folgende Punkte hinzufügen:
-- Passt sich dem nativen Look des Betriebssystemes an. Kann pyGTK nicht (Und ist auch nich deren Konzept). Eine in pyGTK geschriebene Anwendung sieht auf Linux genauso aus wie auf Windows. Den Look kann man aber durch Themes beeinflussen. -- Da ich es aber bevorzuge das sich eine Anwendung dem Look des Betriebssystemes anpasst ist wxPython diesbezüglich die einzige Alternative für mich (pyQT ist wegen des Dual-Lizenz Konzeptes auch keine für mich!).

-- wxPython ist wirklich simpel zu benutzen (Ok, relativ gesehen).

-- wx.aui ist ein Feature mit den man wirklich professionell aussehende Anwendungen gestallten kann (Fenster Management, etc).

-- Für fast alle Aufgabenbereiche gibt es schon fertige Widgets mitgeliefert, die sich größtenteils alle leicht benutzen lassen. Für mich heißt das, dass ich mich nicht um das schreiben von "trivial"-dingen kümern muss, was die Entwicklungszeit sehr verkürzt.

-- wxPython ist **verdammt** schnell, was man zu pyGTK in einigen bereichen @ Windows nicht gerade behaupten kann (BTW: Vom hören und sagen). Im Gegensatz dazu sind aber auch einige Sachen von wxPython @ Linux (z.B.:``wx.ListCtrl``) langsamer als unter Windows. Vieles **lässt** sich aber lösen. z.B. nutzt man statt ListCtrl VirtualListCtrl.



Zu den schwächen von wxPyhon:
-- Beschießen Dokumentation (Sorry für die Wortwahl, aber anders kann ich das nicht bezeichnen!). Entweder die Dokumentation zu einem Widgets ist so knapp, das man um das herumprobieren nicht herum kommt, oder es sind viele Methoden/Widgets garnicht dokumentiert!
Gutes Beispiel (Da sind gerade mal 2 Prozent der Methoden dokumentiert.): http://wxpython.wxcommunity.com/docs/ap ... class.html
Meistens sieht es so aus, das man zwischen http://wxwidgets.org/manuals/2.8.0/wx_contents.html und http://wxpython.wxcommunity.com/docs/api/ am Switchen ist um an die benötigten Infos zu kommen. Nach etwas mehr Erfahrung hat man den Dreh auch raus und hat gelernt um die ecke zu schauen
In einigen wenigen fällen muss man sogar im Sourcecode schauen (Um zumindest zu sehen was an Methoden angeboten wird. -> dir(foo) ist auch nicht unbedingt die beste Lösung , da dazu keine Docs vorhanden sind -> z.B.: wx.lib.iewin und wx.activex

-- In wenigen "speziellen" fällen ist man immer noch darauf angewiesen IDs rumzureichen bzw. zu erstellen, was aber anders nicht zu lösen ist. Dennoch nervig -> z.B.:``wx.Menu``

-- Das alles CamelCase ist finde ich nicht so gut. Das heißt für mich das ich da nach zwei Styleguides arbeite.
Alles was mit GUI zu tun hat, schreibe ich dann nach dem wxPython-Styleguide -> CamelCase für Methoden, mixedCase für Attribute. Den Rest mache ich nach PEP-8, worauf der restliche wxPython Styleguide auch größtenteils basiert. Zwischen Methoden amche ich aber keine 2 Leerzeilen, sondern eine wie in PEP-8 vorgeschlagen.
Alles was mit Logik zu tun hat schreibe ich generell nach PEP-8: lower_case_with_underscores für Funktionen, Attribute, Methoden. Auch an den Rest von PEP-8 halte ich mich größtenteils.
Das führt leider dazu, wenn sich GUI und Logik berührt, das man alles gemischt hat. -- Leider ist wxPython da nicht die Ausnahme. Auch das geniale Beautiful Soup bildet da keine Ausnahme.


Alle von mir aufgezählten schwächen hat pyGTK nicht (Mit den IDs weiß ich nicht da ich mich pyGTK, wegen den genanten gründen, nicht beschäftigt habe).

[gerold]

Hi!

-- wxPython ist **verdammt** schnell, was man zu pyGTK in einigen bereichen @ Windows nicht gerade behaupten kann (BTW: Vom hören und sagen).

pyGTK ist wahrscheinlich die richtige Wahl, wenn man nur GTK-Anwendungen (Gnome) schreiben möchte. wxPython verwendet zur Darstellung unter Linux zwar auch GTK, schiebt aber eine Abstraktionsschicht dazuwischen. Wenn man allerdings plattformunabhängige Anwendungen schreiben möchte, dann ist, meines Erachtens, wxPython die bessere Wahl. wxPython ist näher beim Programmierer, es nimmt ihm/ihr also einiges an Arbeit ab, die bei pyGTK beim Programmierer hängen bleibt -- aber das ist nicht immer das Entscheidungskriterium. Wer hauptsächlich Windows-Anwendungen schreibt, ist mit wxPython sowiso besser drann. --> Schneller, einfacher, mehr Möglichkeiten

die Dokumentation zu einem Widgets ist so knapp, das man um das herumprobieren nicht herum kommt

wxPython lässt sich super programmieren, wenn man eine IDE mit guter Codevervollständigung benutzt. Ich verwende WingIDE, aber auch Eclipse soll nicht schlecht sein.

Ich brauche so gut wie keine Dokumentation, da mir WingIDE im richtigen Augenblick die möglichen Methoden, die zu übergebenden Parameter und deren Docstrings anzeigt. Wenn ich mal nicht weiß, wie ich etwas an einem Widget ändern kann, dann gehe ich die Liste der Methoden durch und weiß, da die Methodennamen aussagekräftig sind, nach wenigen Sekunden, welche Methode ich dafür brauche. Wenn ich unschlüssig bin, dann schaue ich kurz in die wxWidgets-Dokumentation.

oder es sind viele Methoden/Widgets garnicht dokumentiert! Gutes Beispiel (Da sind gerade mal 2 Prozent der Methoden dokumentiert.): http://wxpython.wxcommunity.com/docs/ap ... class.html

wx.aui ist komplett neu und wird derzeit noch entwickelt. Das ist zwar nicht schlecht, aber wer sich auf so neue Techniken einlässt, muss schon mal Abstriche machen. Dann gibt es aber auch noch Widgets, die kaum jemand einsetzt und auch nicht plattformübergreifend verwendbar sind, wie z.B. das wx.lib.iewin, das eine einfach gestrickte Möglichkeit darstellt, den den Internet Explorer als Widget einzubinden. Dabei wurde einfach nur das IE-Control als ActiveX-Control eingebunden. Wenn jemand wissen will, wie dieses IE-Control programmiert werden kann, der kann sich in der Windows-PlattformSDK schlau machen.

In einigen wenigen fällen muss man sogar im Sourcecode schauen

Im WingIDE klicke ich mit der rechten Maustaste auf ein Objekt und dann auf "Gehe zur Definition". Schon bin ich im wxPython-Quellcode, genau an der Stelle, an der das markierte Objekt erstellt wurde. Das ist eine Dokumentation nach meinem Geschmack.

In wenigen "speziellen" fällen ist man immer noch darauf angewiesen IDs rumzureichen bzw. zu erstellen, was aber anders nicht zu lösen ist. Dennoch nervig -> z.B.:``wx.Menu``

Das stimmt nicht:

Code: Alles auswählen

        menubar = wx.MenuBar()
        mnu_file = wx.Menu()
        mnu_f_exit = mnu_file.Append(-1, "E&xit")
        self.Bind(wx.EVT_MENU, lambda event: self.Close(), mnu_f_exit)
        menubar.Append(mnu_file, "&File")
        self.SetMenuBar(menubar)

-- Das alles CamelCase ist finde ich nicht so gut.

Es stört mich zwar auch, aber ich nutze es als Vorteil aus. Die wxPython-Methoden sind mit CamelCase-Namen benannt. Ich schreibe alle Methoden klein. Somit kann ich nicht unabsichtlich wxPython-Methoden überschreiben. Auch wenn ich mal eine close-Methode definiere, überschreibe ich damit nicht die eingebaute Close-Methode. Der wxPython-Styleguide ist, meines Erachtens, nur für die gedacht, die wxPython erweitern. Für die, die wxPython als Framework benutzen, ist er (meiner Meinung nach) Schwachsinn. Was soll die Verwendung von CamelCase innerhalb des Programms bringen? Was soll die Benennung von Event-Handlern mit z.B. "OnClose" oder "OnClick"? Es macht viel mehr Sinn, eine Methode, die ein Frame schließt "close_frame" zu nennen. Oder eine Methode, die mir eine Liste mit Werten füllt, werde ich nicht "OnClick" nennen. Diese wird z.B. "fill_booklist" genannt. Auf so eine Methode kann ich auch außerhalb des Event-Systems von wxPython zugreifen. Deshalb schreibe ich solche Event-Handler auch so, dass sie auch dann funktionieren, wenn ich das Event nicht mit übergebe.

Code: Alles auswählen

def close_frame(self, event = None):
    self.Close()

lg
Gerold

[oliver1974]

Im WingIDE klicke ich mit der rechten Maustaste auf ein Objekt und dann auf "Gehe zur Definition". Schon bin ich im wxPython-Quellcode, genau an der Stelle, an der das markierte Objekt erstellt wurde. Das ist eine Dokumentation nach meinem Geschmack.

DAS vermisse ich noch bei bei Eclipse + PyDev.

Während die CodeCompletion und die Anzeige der DocStrings einwandfrei funktionieren, klappt das Springen in die Sourcen hinein nicht.. bzw. gibt es nicht. Zumindest habe ich es nicht gefunden. Natürlich geht das für Java-Code, aber PyDev scheint da kein Äquivalent zu bieten?

[sape]

die Dokumentation zu einem Widgets ist so knapp, das man um das herumprobieren nicht herum kommt

wxPython lässt sich super programmieren, wenn man eine IDE mit guter Codevervollständigung benutzt. Ich verwende WingIDE, aber auch Eclipse soll nicht schlecht sein.

Ja kann Eclipse auch. Das hat aber nichts mit der Dokumentation zu tun.

Ich brauche so gut wie keine Dokumentation, da mir WingIDE im richtigen Augenblick die möglichen Methoden, die zu übergebenden Parameter und deren Docstrings anzeigt. Wenn ich mal nicht weiß, wie ich etwas an einem Widget ändern kann, dann gehe ich die Liste der Methoden durch und weiß, da die Methodennamen aussagekräftig sind, nach wenigen Sekunden, welche Methode ich dafür brauche. Wenn ich unschlüssig bin, dann schaue ich kurz in die wxWidgets-Dokumentation.

Naja, bei vielen dingen muss man aber wissen wie man die Sachen richtig verwendet -> z.B.: wx.ListCtrl, wx.aui, etc. Alles dinge deren Benutzung mir nicht *so* offensichtlich war. Was ich damit sagen will ist, das es nicht genügt anhand der Namen der Methoden darauf zu schließen wie man das komplette Widget "richtig" benutzt.

oder es sind viele Methoden/Widgets garnicht dokumentiert! Gutes Beispiel (Da sind gerade mal 2 Prozent der Methoden dokumentiert.): http://wxpython.wxcommunity.com/docs/ap ... class.html

wx.aui ist komplett neu und wird derzeit noch entwickelt. Das ist zwar nicht schlecht, aber wer sich auf so neue Techniken einlässt, muss schon mal Abstriche machen.

Ehm es gibt Widgets die schon lange benutzt werden und **nicht neu** sind und eine wirklich schlechte Dokumentation haben. Daher hinkt dein Argument gewaltig. 80% der Dokumetation ist einfach schrott. Wenn ich mir dagegen die Dokumentation von pyGTK anschaue...Da ist die Dokumentation von wx Lichtjahre entfernt.

Dann gibt es aber auch noch Widgets, die kaum jemand einsetzt und auch nicht plattformübergreifend verwendbar sind, wie z.B. das wx.lib.iewin, das eine einfach gestrickte Möglichkeit darstellt, den den Internet Explorer als Widget einzubinden. Dabei wurde einfach nur das IE-Control als ActiveX-Control eingebunden. Wenn jemand wissen will, wie dieses IE-Control programmiert werden kann, der kann sich in der Windows-PlattformSDK schlau machen.

Jepp, nach dem studieren der Sourcecodes weiß ich das auch, das iewin nur ein ActiveX-Con wrappt.
Denoch wäre es **nicht schelcht**, wenn zu mindest das iewin Modul in der von Epydoc generierten Dokumentation auftauchen würde.

In einigen wenigen fällen muss man sogar im Sourcecode schauen

Im WingIDE klicke ich mit der rechten Maustaste auf ein Objekt und dann auf "Gehe zur Definition". Schon bin ich im wxPython-Quellcode, genau an der Stelle, an der das markierte Objekt erstellt wurde. Das ist eine Dokumentation nach meinem Geschmack.

Ja, geht auch in Eclipse BTW: Das ist keine "Dokumentation" nach meine Geschmack. Du wilslt doch den Vorgang "In den Source schauen was für Methoden Objekt X hat" nicht als Dokumentation bezeichnen?!

In wenigen "speziellen" fällen ist man immer noch darauf angewiesen IDs rumzureichen bzw. zu erstellen, was aber anders nicht zu lösen ist. Dennoch nervig -> z.B.:``wx.Menu``

Das stimmt nicht:

Code: Alles auswählen

        menubar = wx.MenuBar()
        mnu_file = wx.Menu()
        mnu_f_exit = mnu_file.Append(-1, "E&xit")
        self.Bind(wx.EVT_MENU, lambda event: self.Close(), mnu_f_exit)
        menubar.Append(mnu_file, "&File")
        self.SetMenuBar(menubar)

Ok, das man das Item direkt angeben kann, wusste ich nicht.
Baer hier ist das nicht möglich (oder?):

Code: Alles auswählen

acell_id1 = wx.NewId()
        accel = wx.AcceleratorTable([
            # Applikation beenden
            (wx.ACCEL_CTRL, wx.WXK_F4, acell_id1),
            (wx.ACCEL_CTRL, ord('Q'), acell_id1)
        ])
        self.SetAcceleratorTable(accel)
        
        def OnClose(event):
            self.Close()
        self.Bind(wx.EVT_MENU, OnClose, id=acell_id1)

-- Das alles CamelCase ist finde ich nicht so gut.

Es stört mich zwar auch, aber ich nutze es als Vorteil aus. Die wxPython-Methoden sind mit CamelCase-Namen benannt. Ich schreibe alle Methoden klein.

Das ist aber kein Argument. Ich finde man sollte sich schon daran halten so wie man sich beim Logischen Teil an PEP-8 hält. Wenn dabei ein Widget rauskommt das vielleciht auch anderen nützlich ist, finde ich es sehr strange damit zu arbeiten weil das alle Konventionen nicht einhält. -- Widgets die sich nicht am Syleguide halten werden z.B. auch nicht im wxPython-"Core" aufgenommen und das zu recht. Genauso wie Python Module die sich nicht an PEP-8 halten auch nicht in die Batteries aufgenommen werden (Ok, die existierenden Ausnahmen lassen wir mal beiseite. In Py3k wird ehe ordentlich ausgemistet.)

Somit kann ich nicht unabsichtlich wxPython-Methoden überschreiben.

Dann sollte man besser aufpassen, ernsthaft! Wenn du von Klasse X aus Package Y erbst (Sagen wir mal als Beispiel einen Lexer aus Pygements den man als Base nimmt), muss du doch auch aufpassen(?). Ich finde nicht, das man sich dann eine eigene Schreibkonvention anlegen sollte **nur** damit man nicht ausersehen eine Methode überschreibt.

Auch wenn ich mal eine close-Methode definiere, überschreibe ich damit nicht die eingebaute Close-Methode. Der wxPython-Styleguide ist, meines Erachtens, nur für die gedacht, die wxPython erweitern. Für die, die wxPython als Framework benutzen, ist er (meiner Meinung nach) Schwachsinn.

Nein der ist nicht Schwachsinn. Guter Stil ist nie Optional. PEP-8 ist **auch** nur dazu da, damit eigene Source in den Batteries aufgenommen werden können. Daher ist das keine wirkliche Begründung von dir. Ich behaupte mal das die Meisten die wxPython nutzen sich auch am Styleguid halten, genauso wie sich auch die meisten an PEP-8 halten. Und beides aus gleichen gründen.

Was soll die Verwendung von CamelCase innerhalb des Programms bringen? Was soll die Benennung von Event-Handlern mit z.B. "OnClose" oder "OnClick"? Es macht viel mehr Sinn, eine Methode, die ein Frame schließt "close_frame" zu nennen.

Nein macht es nicht!

Oder eine Methode, die mir eine Liste mit Werten füllt, werde ich nicht "OnClick" nennen. Diese wird z.B. "fill_booklist" genannt. Auf so eine Methode kann ich auch außerhalb des Event-Systems von wxPython zugreifen. Deshalb schreibe ich solche Event-Handler auch so, dass sie auch dann funktionieren, wenn ich das Event nicht mit übergebe.

Code: Alles auswählen

def close_frame(self, event = None):
    self.Close()

Event-Methoden sollten alle mit einen "On" am Anfang beginnen. Und das hat auch zwei Gründe von dem sich der eine Übersichtlichkeit nennt. An dem "On" erkenne ich und andere sofort das es sich um eine Methode handelt die Events entgegennimmt. Und das ist der zweite Grund der dazu führt das es einem Signalisiert "Halt nicht selber aufrufen, dann Eventmethoden ruft man nicht selber auf".

Wenn ich eine Methode habe die auch so benutzt werden kann und von einem Event, dann schreibe ich die Methode z.B. ``FillBooklist``. So wenn nun ein Event auch dafür zuständig sein soll, da schreibe ich eine Eventmethode die ``FillBooklist`` aufruft.
Den es ist **absolut** unkonventionell Eventmethoden Explizit aufzurufen. Wenn man deren Funktionalität benötigt lagert man das in eine Separate Methode aus, und ruft sie dann von der Event Methode aus auf. Und wenn die Abarbeitung einer Eventmethode vom Event-"Status", etc. abhängig ist und man dennoch so eine Eventmethode Explizit aufrufen möchte (Was ja nicht geht es sei man generiert selber ein Event und übergibt das der Methode.), dann liegt ein genereller Designfehler vor. Das heißt, die Sachen in der Eventmethode die auch separat Funktionsfähig sind, sollte man immer in einer separaten Methode auslagern.

Code: Alles auswählen

class ...
    ...
    def FillBooklist(self):
        pass
    def OnClickBooklist(self, event):
        self.FillBooklist()

Um eine Analogie herbeizuführen: Keiner Benutzt "Private"-Methoden (_ und __ am Anfang) oder? Genauso verhält es sich auch mit einer Eventmethode...


BTW: Zu dem Thema der Dokumentaiotnsqualität von wxPython - Gerold sei mir nicht böse, aber ich finde mal sollte auch Objektiv bleiben. Ich finde deine Argumente bezüglich wxPython Dokumentation sind nicht wirklich Objektiv. Die Dokumentation ist wirklich schwach und da kannst du noch soviel schreiben wie man die Mängel "umgehen" kann, das ändert nichts an der Tatsache.

Wie du und ihr wisst, ist wxPython auch mein Favorit und nutze es auch gerne. Aber ich sehe nicht ein die Schwächen von wxPython mit schwachen Argumenten zu rechtfertigen!

[sape]

Im WingIDE klicke ich mit der rechten Maustaste auf ein Objekt und dann auf "Gehe zur Definition". Schon bin ich im wxPython-Quellcode, genau an der Stelle, an der das markierte Objekt erstellt wurde. Das ist eine Dokumentation nach meinem Geschmack.

DAS vermisse ich noch bei bei Eclipse + PyDev.

Während die CodeCompletion und die Anzeige der DocStrings einwandfrei funktionieren, klappt das Springen in die Sourcen hinein nicht.. bzw. gibt es nicht. Zumindest habe ich es nicht gefunden. Natürlich geht das für Java-Code, aber PyDev scheint da kein Äquivalent zu bieten?

Doch das geht. Dazu hatte ich doch damals, in den einen thread, was zugeschrieben, in dem du das gefragt hatest?

"STRG+Linksklick auf den Namen" und je nach Package/Modul einen Kaffee machen, da es doch mal auf langsamen Rechnern ein wenig dauern kann -- BTW: Vorher das wx Package in der PyDev Umgebung eintragen, sonst geht es bei wx nicht.

[gerold]

Hi sape!

bei vielen dingen muss man aber wissen wie man die Sachen richtig verwendet -> z.B.: wx.ListCtrl, wx.aui, etc. Alles dinge deren Benutzung mir nicht *so* offensichtlich war. Was ich damit sagen will ist, das es nicht genügt anhand der Namen der Methoden darauf zu schließen wie man das komplette Widget "richtig" benutzt.

Es gibt eine wunderbare Dokumentation zu wxPython -- "wxPython in Action". Jeder der mit wxPython produktiv arbeiten möchte, sollte sich dieses Buch zulegen und von vorne bis hinten durchlesen. Da steht alles drinnen was man so zum Programmieren mit wxPython braucht und wissen sollte. Da wird die richtige Verwendung von Menüs genau so gut erklärt, wie die richtige Verwendung von wx.ListCtrl und VirtualListCtrl. wx.aui wird natürlich noch nicht im Buch erklärt -- das ist einfach noch zu neu.

es gibt Widgets die schon lange benutzt werden und **nicht neu** sind und eine wirklich schlechte Dokumentation haben. Daher hinkt dein Argument gewaltig. 80% der Dokumetation ist einfach schrott. Wenn ich mir dagegen die Dokumentation von pyGTK anschaue...Da ist die Dokumentation von wx Lichtjahre entfernt.

Nimm "wxPython in Action" zur Hand, dann hast du eine genau so gute, wenn nicht sogar bessere Dokumentation für wxPython.

Denoch wäre es **nicht schelcht**, wenn zu mindest das iewin Modul in der von Epydoc generierten Dokumentation auftauchen würde.

Jetzt im Ernst. Die wichtigste Dokumentation ist "wxPython in Action". Dann kommt die wxWidgets-Referenz. Die Epydoc-Dokumentation ist nur da, weil diese in wenigen Minuten fast von selbst erstellt werden kann. Das hat aber nichts mit einer Dokumentation zu tun, sondern ist eine schnell gemachte Auflistung der Objekte, die in wxPython verwendet werden können. Dass iewin nicht in dieser Api-Auflistung auftaucht, ist wahrscheinlich nicht gewollt, aber ein kurzer Hinweis an die wxPython-Mailingliste würde wahrscheinlich genügen, um das auszubessern.

Du wilslt doch den Vorgang "In den Source schauen was für Methoden Objekt X hat" nicht als Dokumentation bezeichnen?!

Wie man es nimmt... Ich finde, dass der Python-Quellcode so gut lesbar ist, dass ich sogar in den meisten Fällen zuerst in den Quellcode schaue, bevor ich in irgendeiner Dokumentation nachsehe. Davon ausgenommen ist die die Python-Dokumentation als CHM-Datei. In dieser lässt sich so schnell das Gesuchte finden, dass ich öfter in dieser suche als im Quellcode der Python-Module. Was ich damit sagen will: Für mich persönlich ist ein gut geschriebener Python-Quellcode des öfteren Quell von Inspiration... Das gilt natürlich nicht für jeden.

wx.AcceleratorTable

Die Verwendung der ``wx.AcceleratorTable`` ist ein Fall, wo man nicht um die Verwendung von IDs herum kommt.

Ich finde nicht, das man sich dann eine eigene Schreibkonvention anlegen sollte **nur** damit man nicht ausersehen eine Methode überschreibt.

Da bin ich deiner Meinung. Ich sage nur, dass ich mich beim Programmieren an PEP-8 halte. Dieser bleibe ich treu und werde nicht wegen einem anderen Styleguide, der mich persönlich total abschreckt, groß von PEP-8 abweichen. Der wxPython-Styleguide sollte eigentlich in die wxPython-Dev-Rubrik verschoben werden und nicht direkt von der Startseite aus zugänglich sein. Dieser wxPython-Styleguide macht mehr kaputt als gut. Dieser Stuileguide ist zu sehr an die Schreibweise der C++-Methoden angelehnt und zu weit von Python entfernt.

Es macht viel mehr Sinn, eine Methode, die ein Frame schließt "close_frame" zu nennen.

Nein macht es nicht!

Niemand wird mich davon abhalten. Ich programmiere jetzt seit 21 Jahren und habe meinen Stil immer wieder angepasst, um besseren, durchschaubareren und wartbareren Code zu produzieren. -- Nach meiner Erfahrung, gibt es absolut keinen Grund für mich, einen Event-Handler besonders zu kennzeichnen. Es genügt, wenn als zweiter Parameter ``event`` erwartet wird. Im Gegenteil! Bei vielen Programmen, hat man nur mehr Schreibarbeit und absolut keinen Zusatznutzen. Was bringt es mir zehn Event-Handler zu schreiben, die nichts anderes tun, als eine einzige Methode aufzurufen. Da schreibe ich diese einzelne Methode doch lieber so um, dass diese als Event-Handler verwendet werden kann, als dass ich zig Methoden erzeuge, deren einziger Zweck eine Weiterleitung zur richtigen Methode ist! Wenn es auch nur ansatzweise mehr Durchschaubarkeit des Codes bringen würde, dann würde ich es machen, aber nachdem ich beide Schreibweisen ausprobiert und abgewägt habe, bleibe ich bei meiner Aussage, dass besonders benannte Event-Handler (z.B. OnCloseWidget1 oder OnClickButton2) keinen zusätzlichen Vorteil bringen.

Wenn ich eine Methode habe die auch so benutzt werden kann und von einem Event, dann schreibe ich die Methode z.B. ``FillBooklist``. So wenn nun ein Event auch dafür zuständig sein soll, da schreibe ich eine Eventmethode die ``FillBooklist`` aufruft.

Es hindert dich ja niemand daran.

Um eine Analogie herbeizuführen: Keiner Benutzt "Private"-Methoden (_ und __ am Anfang) oder? Genauso verhält es sich auch mit einer Eventmethode...

Den verstehe ich nicht.

Die Dokumentation ist wirklich schwach

- http://www.manning.com/rappin/
- http://showmedo.com/videos/series?name= ... nersSeries
- http://wiki.wxpython.org/index.cgi/AnotherTutorial
- http://wxwidgets.org/manuals/2.8.0/wx_classesbycat.html
- http://wxpython.org/OSCON2006/
Und die wxPython-Demo als Dokumentation, sollte man auch nicht unterschätzen.

lg
Gerold

[oliver1974]

Doch das geht. Dazu hatte ich doch damals, in den einen thread, was zugeschrieben, in dem du das gefragt hatest?

Ja, die beiden Threads haben sich mittlerweile so entwickelt, dass sie sich irgendwie überlagern.. Hab Deine Nachricht dort auch schon gelesen.

EDIT: "wxPython in Action" kann ich auch empfehlen. Trotzdem hätte ich es auch schöner gefunden, wenn die Doku "von Haus aus" etwas mehr auf Vordermann wäre... In der Regel schaue ich auch noch eher bei der wxWidgets Doku nach als bei der wxPython Doku. Muss man halt um die Ecke denken.

Die Demo von wxPython ist aber auch wirklich zu empfehlen, gerade
weil man da direkt im SourceCode ganz leicht interaktiv ausprobieren kann (genialer Ansatz übrigens) und diese Änderung parellel zum OriginalCode pro Demo ja speichern kann! Ohne die Demo sehe es schon deutlich schlechter um wxPython aus, aber ich finde das reißt wirklich vieles raus.

Ich finde wxPython nach wie vor einfach toll.. Irgendwie
sind viele Sachen einfach "praxisnah". Andere GUI-Frameworks versuchen oft den theoretisch-sauberen, durchaus vielseitigeren Ansatz, vergessen dann aber häufig , dass man in 90 Prozent der Fälle wirklich nur den offensichtlichsten Fall schnell implementieren will.

[PmanX]

Hallo,

und herzlichen Dank für die guten Argumentationen!
Ich möchte sie auch noch nicht unterdrücken.

...
pyGTK ist wahrscheinlich die richtige Wahl, wenn man nur GTK-Anwendungen (Gnome) schreiben möchte. wxPython verwendet zur Darstellung unter Linux zwar auch GTK, schiebt aber eine Abstraktionsschicht dazuwischen. Wenn man allerdings plattformunabhängige Anwendungen schreiben möchte, dann ist, meines Erachtens, wxPython die bessere Wahl. wxPython ist näher beim Programmierer, es nimmt ihm/ihr also einiges an Arbeit ab, die bei pyGTK beim Programmierer hängen bleibt -- aber das ist nicht immer das Entscheidungskriterium. Wer hauptsächlich Windows-Anwendungen schreibt, ist mit wxPython sowiso besser drann. --> Schneller, einfacher, mehr Möglichkeiten
...
wxPython lässt sich super programmieren, wenn man eine IDE mit guter Codevervollständigung benutzt. Ich verwende WingIDE, aber auch Eclipse soll nicht schlecht sein.
...

Vorrangig werde ich für Linux schreiben. Wenn es für W$ genutzt werden sollte, spielt der Style eine untergeordnete Rolle.

Codevervollständigung ist ein sehr starkes Argument.
Die WingIDE ist doch mit pyGTK geschrieben und kann pyGTK-Code nicht vervollständigen?

--> Schneller, einfacher, mehr Möglichkeiten

Kannst Du das etwas genauer beschreiben?
Von wxPython kenne ich jetzt nur VLC.

Ich denke in Gnome stecken sehr viele Mannjahre.

Gruß P.

[gerold]

Vorrangig werde ich für Linux schreiben. Wenn es für W$ genutzt werden sollte, spielt der Style eine untergeordnete Rolle.
[...]
Die WingIDE ist doch mit pyGTK geschrieben und kann pyGTK-Code nicht vervollständigen?

--> Schneller, einfacher, mehr Möglichkeiten

Kannst Du das etwas genauer beschreiben?

Hallo PmanX!

pyGTK fügt sich schöner in eine reine Gnome-Umgebung ein. Dafür bezahlt man aber mit mehr Schreibarbeit. Ich erkläre es einfach mal mit einem Beispiel:

Eine Inputbox mit pyGTK:
Code ausgelagert: http://paste.pocoo.org/show/1199/

Eine Inputbox mit wxPython:
Code ausgelagert: http://paste.pocoo.org/show/1200/

Ich muss aber auch dazu sagen, dass ich schon seit einem Jahr nichts mehr mit pyGTK mache. Es kann also leicht sein, dass in neueren Versionen endlich etwas für die Programmierer gemacht wurde.

Das mit der Codevervollständigung hast du falsch verstanden. Ich wollte damit nur ausdrücken, dass man mit einer guten IDE, die auch Codevervollständigung beherrscht, recht schnell wxPython-GUIs programmieren kann. Das gilt in gleicher Weise auch für pyGTK-GUIs. Die Codevervollständigung hilft bei so etwas enorm. Außer man hat ein gutes Gedächtnis und behält sich die Methoden im Kopf.

Mit "schneller" meine ich, dass wxPython-Programme unter Windows spürbar schneller laufen als pyGTK-Programme. Das gilt aber nur für Windows. Da bei Linux bei wxPython-Programmen eine zusätzliche Abstraktionsschickt zwischen GTK und dem geschriebenen Programm liegt, kann ein wxPython-Programm unter Linux nicht schneller sein als ein pyGTK-Programm. Es ist wahrscheinlich langsamer, aber das kann ich nur ahnen, denn merken tu ich nichts davon.

Mit "mehr Möglichkeiten" meine ich unter anderem, dass wxPython dem Programmierer mehr Widgets und Dialoge zur Verfügung stellt, als pyGTK. Das ist leicht zu beweisen. Sieh dir die Demo von pyGTK an und dann die von wxPython. wxPython hat außerdem ein Grid-Widget mit an Bord. Der Fairness halber muss ich aber auch zugeben, dass pyGTK in Sachen Drucker/drucken inzwischen aufgeholt hat.

mfg
Gerold


Edit: Code ausgelagert

[oliver1974]

Ja, so hatte ich pyGTK auch in Erinnerung... wxPython war da durchweg kompakter, geradliniger....

Dafür hat es wahrscheinlich wieder andere Vorteile....

Da fällt mir der ewige Streit der Java-Fraktion im GUI-Bereich ein:
SWING gegen SWT.. Wie meinte jemand neulich so schön:
"Toll, dass wir die Auswahl haben und darüber überhaupt streiten können!"

Recht hat er.

[Leonidas]

-- Passt sich dem nativen Look des Betriebssystemes an. Kann pyGTK nicht (Und ist auch nich deren Konzept). Eine in pyGTK geschriebene Anwendung sieht auf Linux genauso aus wie auf Windows. Den Look kann man aber durch Themes beeinflussen.

Das ist doch Quatsch. PyGTK kann über die Wimp-Engine ebenso den Nativen Windows-Look haben wie jedes andere Programm. Und ja, sie kommt auch wunderbar mit Themes aus, wie die die von Windows XP genutzt werden.
Es wundert mich wie lange das PyGTK noch vorgeworfen wird.

Anderwerseits finde ich, dass das GTK-Minimalbeispiel ja doch etwas kürzer ist, als das von wx:

Code: Alles auswählen

import gtk
w = gtk.Window()
w.show_all()
gtk.main()

Was die InputBox betrifft ist sie ein klein wenig komplizierter, denn unter GTK darf man auf gtk.Dialog Elemente eigenmächtig herumstellen. Wenn man nur eine InputBox braucht kann man sich auf einfache Weise eine Funktion machen, die eine solche Dialogbox generiert.

Ohne jetzt groß die Fahne für PyGTK oder wxPython schwenken zu wollen - aber Gerechtigkeit muss sein

[PmanX]

...
Mit "mehr Möglichkeiten" meine ich unter anderem, dass wxPython dem Programmierer mehr Widgets und Dialoge zur Verfügung stellt, als pyGTK.
...

Diese mehr Möglichkeiten könnten in einen Glaubenskrieg ausarten.
Gibt es einige Widgets, die man in pyGTK vermißt?

Gruß P.

[Leonidas]

Gibt es einige Widgets, die man in pyGTK vermißt?

Die nötigsten Widgets sind natürlich da - wenn dir ein bestimmtes spezifisches Widget fehlst, kannst du es selbst schreiben. Dazu gibt es Anleitungen, ist also etwas mehr Arbeit aber keine Unmöglichkeit.

Ja, wxPython hat definitiv mehr Widgets, aber die PyGTK-Demo muss ja nicht alle Widgets von PyGTK demonstrieren, also ist sie als Zählgrundlage ungeeignet.

[Groucho]

@Gerold:

Wenn ich frühere Beiträge im Forum ansehe, dann hast Du ursprünglich mit pyGTK begonnen und bist dann auf wxPython umgestiegen.

Kannst Du etwas dazu schreiben, welche Gründe oder Erfahrungen Dich zu dem Umstieg bewogen haben?

[gerold]

Gibt es einige Widgets, die man in pyGTK vermißt?

Hi PmanX!

- Eine einfach zu verwendende ListBox
- Eine InputBox
- Ein besser FileDialog (öffnen, speichern, ...)
- Ein Tabellen-Widget (wie bei Excel)

Mehr fällt mir jetzt nicht ein. Wie geschrieben, setze ich pyGTK ja nicht mehr ein.

mfg
Gerold

[oliver1974]

Ohauerha.. Bevor das ausartet...:

Meiner Meinung nach, können die wenigsten doch wirklich seriös sagen, ob nun X besser ist als Y... Man entscheidet sich in der Regel irgendwann für eines der beiden und hatte damals Gründe dafür, aber aktive Projekte entwickeln sich oft so schnell weiter, dass man dann gar nicht mehr sagen kann, ob die Gründe mittlerweile nicht obsolet sind.... Wer macht sich denn die Mühe nachher noch in regelmäßigen Zeitabständen seine Entscheidung neu in Hinblick auf die aktuelle Situation auf den Prüfstand zu stellen?

Das ist wahrlich nicht nur bei den GUI-Frameworks so...

[PmanX]

Ohauerha.. Bevor das ausartet...:

Meiner Meinung nach, können die wenigsten doch wirklich seriös sagen, ob nun X besser ist als Y...
...

Dieses Thema dient mir als Entscheidungshilfe, auch wenn ich schon eine kleine Bevorzugung habe.
Allumfassend wird nicht entschieden. Pros/Kontras gegeneinander abwägen und einen Entscheidung
treffen die möglichst lange vorteilhaft ist.
Man will kein Narr von Hause aus sein