Empfehlenswerteste GUI in Python?

[Python93]

Hallöchen,
wie mein Betreff schon frägt, wollte ich wissen welches die empfehlenswerteste GUI in Python ist und wieso.

Vielen Dank für die Antworten, im Vorraus.
LG Python93

[deets]

Och moensch. Such doch mal 3 minuten hier im Forum, und du findest dutzende & erschoepfende Disukssionen zu dem Thema.

[webspider]

Protip: Ohne zu wissen was für dich wichtig ist, sind Fragen der Sorte meist sinnlos, da es recht selten vorkommt, dass eine Technologie sie alle übertrumpft.

[ocoal]

Och moensch. Such doch mal 3 minuten hier im Forum, und du findest dutzende & erschoepfende Disukssionen zu dem Thema.

Ist das nicht auch mit ein Problem und legimitiert die Frage des Threaderstellers gerade deswegen?
Es sind:
- zu viele
- teilweise auch recht (ver)alte(te)
- erschöpfte
und folglich nicht immer mehr aktuelle Diskussionen.

Ändern sich hingegen die Technologien (positiv wie negativ)? Ja - wir nennen das Entwicklung.
Ziehen jedoch deswegen alte Threads nach? Werden Meinungen, Einschätzungen und Empfehlungen überdacht, neu betrachtet und ggf. wieder revidiert? In der Regel wohl eher Nein.

Auf die Sufu zu verweisen ist ... sagen wir es mal so ... hier ein wenig einfach gedacht. Mhm?

-Colin-

[DasIch]

Gerade im Bereich von GUIs gibt es quasi gar keine Entwicklung, die alten Threads sind alle noch genauso anwendbar.

[deets]

Auf die Sufu zu verweisen ist ... sagen wir es mal so ... hier ein wenig einfach gedacht. Mhm?

Die Sufu zu ignorieren ist ... sagen wir es mal so ... es sich ein bisschen einfach machen? Mhm?

Ohne den OP da jetzt dissen zu wollen - ich denke, dass die Diskussionen der (ja nicht unendlichen) Vergangenheit schon *sehr* viel Licht ins Dunkel bringen, alleine schon zB bezueglich Verfuegbarkeit auf Plattformen, Lizenzen und in weiten Teilen auch Features.

Wenn sich da informiert wurde im Kontext der angedachten Projekte kann man ja immer noch konkreter nachfragen.

[lunar]

@DasIch: Wann hast Du Dich denn das letzte Mal mit dem Thema graphische Oberflächen beschäftigt, dass Du da gar keine Entwicklung siehst?!

[ocoal]

Gerade im Bereich von GUIs gibt es quasi gar keine Entwicklung, die alten Threads sind alle noch genauso anwendbar.

Bist Du Dir da sicher - und wie würdest Du denn dann das hier nennen:
- Übersicht über geschlossene Tkinter Issues
- QT Changes
- wxPython Changes

... Stagnation?

Ohne den OP da jetzt dissen zu wollen - ich denke, dass die Diskussionen der (ja nicht unendlichen) Vergangenheit schon *sehr* viel Licht ins Dunkel bringen, alleine schon zB bezueglich Verfuegbarkeit auf Plattformen, Lizenzen und in weiten Teilen auch Features. ...

Ohne Dich jetzt angreifen zu wollen ... aber benutz mal die Sufu und poste den Request (die Parameter), mit dem ein - vielleicht sogar "Neuling" - diese Informationen aus der Sufu entlocken kann .

... Wenn sich da informiert wurde im Kontext der angedachten Projekte kann man ja immer noch konkreter nachfragen.

Hier verstehe ich leider nicht genau was Du damit aussagen willst.
Meinst Du, man könnte dem Threadersteller mehr "Tipps" oder "Empfehlungen" hinsichtlich eines der GUI-Frameworks geben, wenn er mehr über die Verwendung (sprich: sein(e) Projekte) kunde geben würde?

-Colin-

[DasIch]

@DasIch: Wann hast Du Dich denn das letzte Mal mit dem Thema graphische Oberflächen beschäftigt, dass Du da gar keine Entwicklung siehst?!

Tkinter ist immer noch so eingeschränkt dass es quasi unbrauchbar ist, wx hat immer noch eine bestenfalls komische API, GTK ist immer noch schlecht dokumentiert und Qt so ziemlich die erste Wahl wenn man eine halbwegs angenehme API, halbwegs gute Dokumentation und Platformunabhängigkeit haben will, alles andere ist nicht die Erwähnung wert.

Die einzige hilfreiche Entwicklung ist PySide, welches die Lizenzproblematik für Qt gelöst hat. Sicherlich drehen die Entwickler nicht alle Däumchen aber etwas was die Antwort dieser Frage ändern würde haben sie auch nicht produziert.

[BlackJack]

Also ich sehe auch keine Entwicklung *bezüglich der Frage*. Natürlich gibt's geschlossene Bugs und neue Features, aber was hat sich denn dadurch an den ewig selben Antworten auf die immer gleiche Frage geändert? `Tk` hat immer noch weniger Widgets als die Konkurrenz, `wxWidgets` merkt man immer noch die verstaubte API an, für PyQt und PySide gilt immer noch was über die Lizenzen gesagt wird, und am Pro und Contra Gtk vs. Qt hat sich was genau geändert?

[mutetella]

Was mir bei vielen "soll-ich-das-oder-das-framework-nehmen"-Diskussionen fehlt, ist der Verweis auf die gute alte Tante Terminal. Eine gut durchdachte TUI oder eine Anwendung auf Konsolenbefehl-Ebene mit einer eingängigen Argumentenübergabe können IMHO mit GUI's mehr als mithalten, sind oftmals sogar sinniger.
Auf den ersten Blick mögen textbasierte Anwendungen 68er mäßig daherkommen. Aber auch im Jahr 2012 stellen sie durchaus eine ernste Alternative dar.
Und nicht nur blond, auch grau kann durchaus sexy sein und ist dabei oft nicht so oberflächlich, wie so manch bunt geschminkte Schönheit...

Ein Beispiel für eine IMHO sehr gelungene textbasierte Anwendung ist ranger, ein Dateimanager, seit dessen Verwendung ich so gut wie nie mehr auf Nautilus oder Kollegen zurückgreifen musste/wollte.
ranger verwendet curses. Eine sehr gute Alternative zu curses findet man mit urwid.

So, das war mein Senf zum Thema UI.

mutetella

[lunar]

@BlackJack: Gtk hat Qt inzwischen einiges voraus, unter anderem

• eine einheitliche und abstrakte Rendering-Engine, dank derer man Gtk-Anwendungen nahezu unverändert in verschiedene Backends rendern kann (u.a. X11, OpenGL, Wayland oder HTML5),
• bessere Multimedia-Unterstützung, denn gstreamer ist flexibler und ermöglicht insbesondere den direkten Zugriff auf die Eingabedaten und die Manipulation derselben,
• und mit GI ein einheitliches Metadatenmodell für Bibliotheksschnittstellen, dank dessen Drittbibliotheken ohne dedizierte Python-Anbindungen verwendet werden können, was Python-Entwicklern sowohl mehr Bibliotheken an die Hand gibt, als auch das Deployment vereinfacht.

Demgegenüber hat Qt mit QML und QtQuick eine deklarative Beschreibungssprache für Oberflächen, die für manche Anwendungen den Python-Quelltext auf das Laden der Qt-Laufzeitumgebung beschränkt, und bessere Unterstützung für Animationen.

Beiden Toolkits dagegen ist gemein, dass sie hinter der Konkurrenz aus anderen Sprache ziemlich weit zurückgefallen sind. Cocoa war vielleicht schon immer besser, und Microsoft hat mit WPF mittlerweile ein mächtiges und modernes Toolkit, und einige sehr interessante Bibliotheken in diesem Umfeld. Ich persönlich jedenfalls würde WPF jederzeit Qt vorziehen, zumindest unter den Kriterien Komfort und Features.

Dazu kommt, dass weder Python noch Gtk oder Qt in absehbarer Zeit von einer nennenswerten Mobilplattform unterstützt werden. Vor diesem Hintergrund würde ich heute auf die Frage, ob Gtk oder Qt das bessere Toolkit für Python ist, antworten, dass Python selbst vielleicht keine gute Wahl für graphische Oberflächen mehr ist, je nachdem welche Zielgruppe man hat.

[noisefloor]

Hallo,

womit wir wieder da wären:

Ohne zu wissen was für dich wichtig ist, sind Fragen der Sorte meist sinnlos, (...)

Ansonsten finde ich die Zusammenfassung von lunar sehr gelungen und treffend.

Gruß, noisefloor

[Leonidas]

@BlackJack: Gtk hat Qt inzwischen einiges voraus, unter anderem

Ja, das ist ja schön, ich mag GTK+ auch. Aber für viele Diskussionen sind die von dir angesprochenen Punkte gar nicht von Belang. Ich habe noch nie einen Thread gesehen, wo ein Anfänger nach einem Toolkit gesucht hat, welches eine abstrakte Rendering Engine hat. Da kommen eher so triviale Sachen wie Windows und Mac-Support, welches im Fall von Windows "naja, es geht schon" und im Fall von Mac OS X eher "ja, da brauchst du halt X11 und dann schauts bäh aus" zu beantworten ist. Außer ich habe jetzt grob was verpasst.

Und das GTK+ praktischer war, was Anbindungen angeht, das war schon seit langem so, so ein Binding über ctypes war schon seit langem recht trivial realisierbar, jetzt ist es halt sogar automatisierbar, zur Laufzeit. Kein Vergleich zu SWIG oder SIP im Fall von PyQt. Und Python-Bindings gab es ja schon vorher für viele Sachen aus der GTK+-Ecke, wenn ich mich Richtig erinnere hatte GNOME es sich ja auch auf die Fahne geschrieben möglichst unabhängig von der Programmiersprache zu sein, wohingegen im KDE-Umfeld der Fokus eher auf C++ lag, und die Bindings waren dann so stiefmütterlich (PyKDE, anyone?).

Dazu kommt, dass weder Python noch Gtk oder Qt in absehbarer Zeit von einer nennenswerten Mobilplattform unterstützt werden. Vor diesem Hintergrund würde ich heute auf die Frage, ob Gtk oder Qt das bessere Toolkit für Python ist, antworten, dass Python selbst vielleicht keine gute Wahl für graphische Oberflächen mehr ist, je nachdem welche Zielgruppe man hat.

Gut, aber außer für Cocoa gilt das für andere UIs genauso. Wenn man jetzt nicht umbedingt in die Windows Phone-Nische will. Generell ist es auch nicht so wichtig, weil man kann Desktop-UIs eh nicht aufs Handy übertragen, Maemo-Style, ohne dass die Usability leidet. Da muss man meist das UI entsprechend für die Platform designen, und dafür dann ein anderes Toolkit zu nehmen als für das Desktop-UI halte ich, bei all dem anderen nötigem Aufwand für eine Mobil-Version einer App für annehmbar. Zudem jetzt Python weder für Android noch iOS-Apps jetzt eine besonders tolle Wahl ist.

Die Sache ist halt die: was sind die Anforderungen. Da haben BlackJack und DasIch ganz recht, der Threadersteller hätte einfach suchen können und wär auf für ihn relevante Diskussionen gestoßen. Oft ist es so, dass wenn man Spezialanforderungen wie etwa Rendering in Canvas oder Desktop- und Mobil-UI haben will, dann eh schon weiß was für ein Toolkit man nehmen will.

[jens]

Wäre es nicht Sinnvoll eine Wiki Seite zu machen, bei der man die einzelnen GUI Toolkits vorstellt inkl. der Vor-/Nachteile? Dann könnte man immer wieder darauf verweisen.

Im übrigen haben wir schon ein paar Seiten dazu: http://wiki.python.de/Tags/Gui

Zu den wichtigsten gibt es auch eine Seite:
http://wiki.python.de/PyGTK
http://wiki.python.de/PyQt
http://wiki.python.de/Tkinter
http://wiki.python.de/wxPython

Was fehlt ist ein Vergleich. btw. ist ein Wiki, jeder kann und sollte mitmachen

Im englischen Wiki gibt es auch noch Futter:
http://wiki.python.org/moin/GUI%20Progr ... n%20Python
http://wiki.python.org/moin/GuiProgramming


Eine Auswahlhilfe gibt es hier: http://www.awaretek.com/toolkits.html Keine Ahnung wie aktuell und aussagekräftig das ist.

[Leonidas]

Eine Auswahlhilfe gibt es hier: http://www.awaretek.com/toolkits.html Keine Ahnung wie aktuell und aussagekräftig das ist.

Das bietet tatsächlich Easygui, PythonCard, fxpy, Pygui und Anygui an. Ich denke die meisten waren schon tot als ich vor fast 10 Jahren mit Python angefangen habe, und alle kurz danach.

[mutetella]

@Python93
Mich hätte jetzt einfach mal interessiert, für welches Programm Du ein GUI-Framework suchst...

mutetella

[Kebap]

+1

Wäre es nicht Sinnvoll eine Wiki Seite zu machen, bei der man die einzelnen GUI Toolkits vorstellt inkl. der Vor-/Nachteile? Dann könnte man immer wieder darauf verweisen.

Im übrigen haben wir schon ein paar Seiten dazu: http://wiki.python.de/Tags/Gui

Zu den wichtigsten gibt es auch eine Seite:
http://wiki.python.de/PyGTK
http://wiki.python.de/PyQt
http://wiki.python.de/Tkinter
http://wiki.python.de/wxPython

Was fehlt ist ein Vergleich. btw. ist ein Wiki, jeder kann und sollte mitmachen

Im englischen Wiki gibt es auch noch Futter:
http://wiki.python.org/moin/GUI%20Progr ... n%20Python
http://wiki.python.org/moin/GuiProgramming

(nochmal full quote wegen seitenumbruch)

[Leonidas]

Ich hab mal die Artikel drübergelesen und die sind zum größten Teil völlig für die Tonne. Das schlimmste ist, das ich da an einigen (vor mindestens 6 Jahren, sei zu meiner Verteidigung erwähnt) mitgeschrieben habe.

[jens]

ist ein Wiki, jeder kann und sollte mitmachen