Tips für Graphische Benutzeroberfläche, einlesen von txt Dat

[player_ben]

Hallo zusammen,
Ich möchte eine Graphische Benutzeroberfläche für einen geschriebenen Python-code erstellen. Jetzt habe ich gelesen, dass es mehrere Oberflächen gibt.
Tkinter, PyGtk, PyQt, wxPython.
Ich weiß gar nicht so recht wo der Vorteil oder unterschied zwischen diesen ist, der Vorteil von Tkinter ist wohl das er schon in der Standard Bib ist.
Eine Funktion die in die Oberfläche integriert werden muss, ist dass ich txt Dateien über die Graphische Oberfläche einlesen kann. Am besten wäre es per Explorer und Mausklick.

Ist dieses überhaupt möglich?
Danke

[Pekh]

Alles, was du von anderen Programmen kennst, ist möglich. Die Frage ist immer, wie viel Aufwand du dafür betreiben mußt.

TKinter ist nur unter Windows standardmäßig mit installiert. Und auch dort kann man es während der Installation von Python abwählen, so daß ich das nicht als Kriterium heranziehen würde. Es ist für kleinere Sachen ganz brauchbar, stößt aber irgendwo auch an Grenzen.

Ich selbst habe lange wxPython genutzt, weil es einem viele Dinge abnimmt, um die man sich in anderen Toolkits selbst kümmern muß. Das geht aber natürlich zu Lasten der Flexibilität, weshalb ich kürzlich auf PyGTK umgeschwenkt bin. Trotzdem würde ich dir wxpython für den Einstieg empfehlen, auch weil die Installation unter Windows wesentlich einfacher ist. Und man kommt ebenfalls sehr weit damit.

[Hyperion]

Trotzdem würde ich dir wxpython für den Einstieg empfehlen, auch weil die Installation unter Windows wesentlich einfacher ist. Und man kommt ebenfalls sehr weit damit.

Na dann werfe ich doch mal PyQt ein. Ist ebenfalls einfach zu installieren und bietet aber - im Gegensatz zu wxPython afaik - bereits Unterstützung für Python3. Evtl. ist das ja durchaus ein wichtiges Kriterium.

So, wer sagt nun ähnliches für PyGtk?

@Op: Prinzipiell ist das alles zum größten Teil Geschmackssache. Viele nutzen eben ein Toolkit, weil sie es bereits beherrschen oder evtl. von anderen Sprachen her schon kennen. (So gehts mit bei PyQt) Die von Dir grad beschriebene Anforderung ließe sich sicherlich mit allen Toolkits in wenigen Zeilen umsetzen. Insofern kannst Du hier eigentlich wenig "falsch" machen. Nimm einfach das Toolkit, was Deinen Anforderungen am besten entspricht und versuche Dich damit

[3ff]

@hyperion,
einem Anfänger pyqt zu empfehlen?
Dann muß man ihm auch klar sagen, wie es um die DOKU bestellt ist!
Einfach installiert JA.
Professionell JA
Alles dicke JA
Probleme gibts erst später, wenn Fehler über Fehler kommen.
ich geb Dir natürlich recht, wenn man von cpp kommt, dann ist alles einfacher.
Wir nehmen für einfache GUI nach wie vor tkinter
Ich schreib auch datenbankanwendungen. Da gibts tolle Beispiele in cpp, aber nicht in PyQT oder PySide.
Das beste Beispiel, was ich hier im Forum gelesen hab, stammt vom Gerold.
Guude!
Fritz

[fon77]

Ich hab mich als Python-Anfänger auch für PyQt entschieden - aus dem einfachen Grund dass ich unter Linux mit KDE unterwegs bin und dort das gleiche Toolkit als Basis dient.

@3ff: Ich war zwar nur Python-Neuling und kein Programmieranfänger, aber ich hatte mit PyQt kaum Probleme und fand die Doku eigentlich bemerkenswert umfänglich und verständlich. Wenn's bei der PyQT-Doku nicht weitergeht kann man ja noch auf die Original-Doku für C++ schauen - die Syntaxunterschiede hat man eigentlich recht fix ausgeblendet.

[Hyperion]

Probleme gibts erst später, wenn Fehler über Fehler kommen.

Und das ist bei anderen Toolkits anders? :K

Probleme gibt es sicherlich immer. Und nur weil Du die Doku von (Py)Qt nicht magst, muss das nicht für andere gelten. Im übrigen empfehle ich einem Anfänger sich nicht mit GUI Programmierung zu befassen. Denn genau dann treten Probleme auf, die nichts mit dem Toolkit zu tun haben, sondern ihre Ursache in den mangelnden Kenntnissen und Fähigkeiten des Programmier- / (Sprach)-Neulings haben.

Edit: Weil mir so langweilig war grad: editor.py, ui-File

[player_ben]

@all: danke für die verschiedenen blickwinkel
@ Hyperion:
interessanterweise ist das pyqt schon installiert gewesen, denn als ich deine datein (danke dafür) eingegeben habe, öffnete sich ein QT-Designer. Wie ist denn nun der zusammenhang, zwischen der .py datei und der .ui datei. in dem designer erstelle ich die oberfläche und den python code erstelle ich wie immer?
oder wird alles in dem designer erstellt?

[BlackJack]

@player_ben: Die `*.ui`-Datei wird mit dem Designer erstellt, die Python-Datei von Hand geschrieben. Da wird die `*.ui`-Datei in Zeile 11 geladen.

[Francesco]

Ich selbst habe lange wxPython genutzt, weil es einem viele Dinge abnimmt, um die man sich in anderen Toolkits selbst kümmern muß. Das geht aber natürlich zu Lasten der Flexibilität, weshalb ich kürzlich auf PyGTK umgeschwenkt bin. Trotzdem würde ich dir wxpython für den Einstieg empfehlen, auch weil die Installation unter Windows wesentlich einfacher ist. Und man kommt ebenfalls sehr weit damit.

Mich würde hier interessieren, wo das "zu Lasten der Flexibilität" genau geht? Ich meine ich stelle damit deine Aussage nicht in Zweifel damit. wxPython hat auch so gewissen unschöne Sachen, wie zb kleine Unterschiede zwischen gtk und Windows (nicht das Aussehen gemeint). Und mit Sizers kann ich mich auch nicht recht anfreunden, obwohl ich mich mit gui designern noch schlechter anfreunden kann. Ich kann mir schon vorstellen, dass pyGTK in gewissen Dingen flexibler ist, aber bei welchen Sachen (Menge an Controls, das verbinden von Events, die Möglichkeiten eines Controls selbst?) wxPython verwendet ja auch gtk für Linux Plattformen.

[Hyperion]

interessanterweise ist das pyqt schon installiert gewesen, denn als ich deine datein (danke dafür) eingegeben habe, öffnete sich ein QT-Designer. Wie ist denn nun der zusammenhang, zwischen der .py datei und der .ui datei. in dem designer erstelle ich die oberfläche und den python code erstelle ich wie immer?
oder wird alles in dem designer erstellt?

Siehst Du, genau das meinte ich oben, als ich über die Probleme bei Anfängern geschrieben habe. Nichts für ungut, aber genau deswegen muss man gründlich die Doku (PyQt von Riverbank) studieren und sich ggf. zusätzlich die Tutorials und Howtos von Nokia (Qt) durchlesen. Der Abschnitt zum QtDesigner sollte dann klären, was es mit der ui-Datei auf sich hat. Die Doku + mein Snippet erklären und demonstrieren dann, wie man mit Python und PyQt die ui-Daten zur Laufzeit läd und daraus die GUI erstellt.

Hinzu kommt dann vor allem der Signal/Slot-Mechanismus, den man als Anfänger ohne gute Kenntnisse des Objekt-Modells von Python nur schwer in ganzer Tiefe durchschauen wird.

Ggf. dann noch das MVC-Konzept von (Py)Qt für die verschiedenen Views.

Als letztes bleibt dann eben noch die Doku zu den einzelnen Widget-Klassen, um zu gucken, welche Methoden und Properties diese so besitzen.

Bei anderen Toolkits sieht es durchaus ähnlich aus, auch wenn sich einige Konzepte sicherlich unterscheiden bleibt auch da, die Grundlagen der Komponenten zu kennen bzw. kennen zu lernen.

BJ hat es Dir ja nun bereits erklärt, aber genau diese Nachfrage Deinerseits zeigt mir, dass Du vermutlich mit dem Aspekt GUI-Programmierung noch überfordert bist.

Ich will Dich wirklich nicht entmutigen, sondern eher ermutigen! Versuche noch intensiver zu lernen; auch, wie man sich selber hilft. Recherche ist eben das A und O in allen Bereichen der Programmierung. Nachfragen sind ja auch durchaus erwünscht, nur zeigen manche eben eher, dass der Verfasser sich keine Mühe gibt oder es nicht wirklich ernst meint. Und damit wird man auf Dauer nicht weit kommen.

Ich hatte dieses kleine Beispiel eher mal reingeklatscht, damit Du Dir mal ein kleines Bild machen kannst, wie so etwas einfaches von Dir oben geschildertes konkret aussieht. Einfach den Schnipsel nehmen und durch naives Abändern PyQt lernen wird Dir da nicht viel bringen

[Pekh]

Ich selbst habe lange wxPython genutzt, weil es einem viele Dinge abnimmt, um die man sich in anderen Toolkits selbst kümmern muß. Das geht aber natürlich zu Lasten der Flexibilität, weshalb ich kürzlich auf PyGTK umgeschwenkt bin. Trotzdem würde ich dir wxpython für den Einstieg empfehlen, auch weil die Installation unter Windows wesentlich einfacher ist. Und man kommt ebenfalls sehr weit damit.

Mich würde hier interessieren, wo das "zu Lasten der Flexibilität" genau geht? Ich meine ich stelle damit deine Aussage nicht in Zweifel damit. wxPython hat auch so gewissen unschöne Sachen, wie zb kleine Unterschiede zwischen gtk und Windows (nicht das Aussehen gemeint). Und mit Sizers kann ich mich auch nicht recht anfreunden, obwohl ich mich mit gui designern noch schlechter anfreunden kann. Ich kann mir schon vorstellen, dass pyGTK in gewissen Dingen flexibler ist, aber bei welchen Sachen (Menge an Controls, das verbinden von Events, die Möglichkeiten eines Controls selbst?) wxPython verwendet ja auch gtk für Linux Plattformen.

Konkret ging es bei mir um die Umsetzung des MVP-Patterns bei Dialogen. Ich hatte immer massive Probleme, die Dialoge und Validatoren zu testen. Was zum Teil sicherlich an Unkenntnis und Denkfehlern lag, zum Teil aber auch daran, daß wxpython einen bisweilen in Bahnen zwingt, die eine saubere Aufteilung von Logik und Oberfläche erschweren. Zumindest in der Art und Weise, die ich bevorzuge. Wenn einem viele Handgriffe abgenommen werden, heißt das halt auch, daß man weniger Einfluß darauf nehmen kann, wie und wo eine Sache erledigt wird.

[Francesco]

Konkret ging es bei mir um die Umsetzung des MVP-Patterns bei Dialogen. Ich hatte immer massive Probleme, die Dialoge und Validatoren zu testen. Was zum Teil sicherlich an Unkenntnis und Denkfehlern lag, zum Teil aber auch daran, daß wxpython einen bisweilen in Bahnen zwingt, die eine saubere Aufteilung von Logik und Oberfläche erschweren. Zumindest in der Art und Weise, die ich bevorzuge. Wenn einem viele Handgriffe abgenommen werden, heißt das halt auch, daß man weniger Einfluß darauf nehmen kann, wie und wo eine Sache erledigt wird.

Aha, und das ist bei pyGTK besser gelöst? Ich kann mir das so vorstellen, weil gtk pythonischer implementiert ist als die wrapper auf Basis des C++ wxWidgets.

Ein Vorteil ist sicher auch, dass es auf Windows und Gtk gleich aussieht (oder gleich aussehen müsste oder auch ein Nachteil, je nachdem wie mans sieht). Vorteil für den Programmierer bei gtk, Vorteil wxPython beim Anwender, wenn er/sie die "vertrauten" Fenster sieht.

[Pekh]

Konkret ging es bei mir um die Umsetzung des MVP-Patterns bei Dialogen. Ich hatte immer massive Probleme, die Dialoge und Validatoren zu testen. Was zum Teil sicherlich an Unkenntnis und Denkfehlern lag, zum Teil aber auch daran, daß wxpython einen bisweilen in Bahnen zwingt, die eine saubere Aufteilung von Logik und Oberfläche erschweren. Zumindest in der Art und Weise, die ich bevorzuge. Wenn einem viele Handgriffe abgenommen werden, heißt das halt auch, daß man weniger Einfluß darauf nehmen kann, wie und wo eine Sache erledigt wird.

Aha, und das ist bei pyGTK besser gelöst? Ich kann mir das so vorstellen, weil gtk pythonischer implementiert ist als die wrapper auf Basis des C++ wxWidgets.

Ein Vorteil ist sicher auch, dass es auf Windows und Gtk gleich aussieht (oder gleich aussehen müsste oder auch ein Nachteil, je nachdem wie mans sieht). Vorteil für den Programmierer bei gtk, Vorteil wxPython beim Anwender, wenn er/sie die "vertrauten" Fenster sieht.

Naja, ob besser lasse ich mal dahingestellt. Es ist anders gelöst, und dieses "anders" entspricht mehr meinen Vorlieben. Aber schon allein die Tatsache, daß man nicht bestimmte Methoden (deren Namen natürlich nicht pep8-konform sind) überschreiben muß, um ein bestimmtes Verhalten hinzubekommen ist in meinen Augen ein Vorteil. Das ist natürlich rein subjektiv und wirkt sich vermutlich auch nicht objektiv meßbar aus. Auf der anderen Seite steht der Mehraufwand, den diese Freiheit mit sich bringt. Und da muß halt jeder für sich entscheiden, wie viel für ihn akzeptabel ist. Ich halte wxPython ja auch nicht für schlecht, es sagt mir halt nur nicht ganz so sehr zu wie pyGTK. Einem Anfänger möchte ich im Zweifel dann aber doch zu wxPython raten. GUI-Programmierung bleibt auch so noch anstrengend genug.

[Francesco]

Was ich mir schon öfters gedacht habe:

Ideal wäre es ein kleines, aber abgeschlossenes, funktionsfähiges, gut dokumentiertes Programm mit gesamten Quellcode in den Implementierungen wxPython, gtk, qt und tkinter nebeneinander zu sehen (oder auch noch andere). Erstens kann man dann schon vom Stil (vom Code) sehen, was einem mehr anspricht, dann kann man auch noch das optische Aussehen beurteilen, ob das jmd. zusagt.

[Pekh]

Was ich mir schon öfters gedacht habe:

Ideal wäre es ein kleines, aber abgeschlossenes, funktionsfähiges, gut dokumentiertes Programm mit gesamten Quellcode in den Implementierungen wxPython, gtk, qt und tkinter nebeneinander zu sehen (oder auch noch andere). Erstens kann man dann schon vom Stil (vom Code) sehen, was einem mehr anspricht, dann kann man auch noch das optische Aussehen beurteilen, ob das jmd. zusagt.

Das Problem ist doch: Wer beherrscht alle diese Toolkits gleichermaßen gut, daß er das leisten könnte? Ich würde es mir nicht zutrauen, in jedem Toolkit "schön" zu programmieren. Wenn es aber vier verschiedene Personen machen, hast du wieder das Problem, daß du nicht sagen kannst, ob eine bestimmte Design-Entscheidung jetzt durch das Toolkit erzwungen / begünstigt wurde, oder ob es eine Frage des persönlichen Stils ist.

[Leonidas]

Wenn es aber vier verschiedene Personen machen, hast du wieder das Problem, daß du nicht sagen kannst, ob eine bestimmte Design-Entscheidung jetzt durch das Toolkit erzwungen / begünstigt wurde, oder ob es eine Frage des persönlichen Stils ist.

Naja, sowas kann noch diskutiert werden. Was viel schwerer zu sagen ist die Frage, was das Programm eigentlich machen soll. Einige Dinge sind in einigen Toolkits einfacher, andere schwerer. Daraus kann man nur bedingt weit auf den Rest des Toolkits schließen. So finde ich einfache Fenster in PyGTK einfacher als in wxPython da man nicht mit Paneln hantiert, aber der Treeview in GTK ist komplizierter zu nutzen als das entsprechende Widget in wxPython.

[lunar]

@Pekh: Deswegen ist umso wichtiger, sich gesunde Vorurteile zu bilden, damit man wenigstens über irgendwas diskutieren kann

Größere Erfahrung habe ich zwar nur mit Qt, von wxWidgets aber rate ich dennoch ab. Nicht, weil ich mit wx größere Programme geschrieben und dabei Unzulänglichkeiten entdeckt hätte, sondern weil mich manche Stellen der wxWidgets-API sowie Auszüge aus dem Changelog an Sorgfalt und Kompetenz der Entwickler zweifeln lassen. Auch ohne größere Erfahrungen mit dem Toolkit traue ich mir zu, auf dieser Grundlage eine Meinung zu bilden, und diese auch argumentativ zumindest etwas begründen zu können.

Demgegenüber hinterlässt Qt4 bei mir den Eindruck, dass die Entwickler sich viele Gedanken um Entwurf und Implementierung gemacht haben, und im Allgemeinen wissen, was sie tun. Auch das kann ich begründen, aber ich denke, dass würde zuweit führen, und wäre nicht ganz On-Topic, da es weniger mit PyQt4, sondern vielmehr mit Qt selbst und dessen Implementierung in C++ zu tun hat.

[Leonidas]

Nicht, weil ich mit wx größere Programme geschrieben und dabei Unzulänglichkeiten entdeckt hätte, sondern weil mich manche Stellen der wxWidgets-API sowie Auszüge aus dem Changelog an Sorgfalt und Kompetenz der Entwickler zweifeln lassen. Auch ohne größere Erfahrungen mit dem Toolkit traue ich mir zu, auf dieser Grundlage eine Meinung zu bilden, und diese auch argumentativ zumindest etwas begründen zu können.

Ich habe selbst unangenehme Erfahrungen mit einigen Bugs in wxPython gemacht, dennoch würden mich deine Kritikpunkte zu wx interessieren. Könntest du das etwas ausführen?

[lunar]

http://www.python-forum.de/viewtopic.ph ... 91#p165791
http://www.python-forum.de/viewtopic.ph ... 27#p165827