Welche GUI-Toolkits verwendet ihr?

[name]

Ich nehm wxPython, finds einfach gut, bis auf das lib.iewin.IEHtmlWindow, das ist echt scheisse und undokumentiert
Ich find wxPython schoen simpel und einfach, aber trotzdem maechtig.

So long..

[skypa]

Also kann ich mir Tkinter anscheinend mit ruhigen Gewissen beibringen ohne nachher Zeit vergeudet zu haben wenns um plattformunabhängige Programme geht...

Aber was bietet sich im wirkliche grafischen Bereich?
pygame?:

import pygame
from pygame.locals import *

-> No module named locals.... lol?

wxPython?

Blender?

[Leonidas]

Also kann ich mir Tkinter anscheinend mit ruhigen Gewissen beibringen ohne nachher Zeit vergeudet zu haben wenns um plattformunabhängige Programme geht...

Vom Überfluss an Wissen wirst du sicherlich nur profitieren.

Aber was bietet sich im wirkliche grafischen Bereich?

Was definierst du als wirklich grafisch? Tkinter ist wirklich, echt und wahrhaftig grafisch.

import pygame
from pygame.locals import *

-> No module named locals.... lol?

Warum fragst du zweimal das gleiche? In diesem Thread geht es um einen Überblick über GUI-Toolkits, nicht um irgendwelche Fehler die du findest. Dazu machst du einfach einen neuen Thread auf.

Blender?

Blender ist gar kein Toolkit sondern ein Modelling-Programm mit Python-Interface. Du nutzt ja auch kein AutoCAD als grafisches Toolkit für AutoLisp.

[gummibaerchen]

Hans, da wäre doch Kylix was für dich, oder nicht?

Für die es nicht wissen: Kylix == Delphi für Linux. Auch von Borland.

Naja, wohl besser Lazarus mit FreePascal

Das ist mal richtig nett für GUIs, da es unter KDE, Gnome, Windows und auch Mac immer nativ ist. Mein Favorit für GUIs, aber wie gesagt leider nur FreePascal.

[joost]

Hi,

da dies bei einer Umfrage steht, kann man wohl in aller Ruhe etwa Senf dazugeben.

Tkinter hat kein Tabellen-Widget und scheidet für damit für ernsthafte db-gestützte Anwendungen aus !! Leider. Dafür Labels in ein Canvas zu schichten ist viel zu langsam, auf 10.000 Zeilen habe ich einmal eine halbe Stunde gewartet, um das Programm dann ergebnislos zu beenden (und 10.000 Zeilen sollte eine Tabelle können - das kann man gerade noch scrollen, um sich einen ersten Überblick zu verschaffen).

Außerdem hat Tkinter den - im Hinblick auf die 10.000 Zeilen für mich unverzeihlichen - Fehler, noch einen tcl-Interpreter starten zu müssen, wo man doch in Python alles Erforderliche hat (hashables) vor allem. Das macht das Zeug langsam, den Code deutlich schwerer zu debuggen usw. usw. . Klar: TK zu ent-tcl-en wäre ein mittelgroßes Projekt (hab den Source-Code schon mal daraufhin durchgesehen, übersichtlich organisiert sind die 20MB schon. Man müsste für maximale Effizienz dafür aber mit tcl/TK-Spezis zusammenarbeiten, die daran wiederum bestimmt kein Interesse haben). Aber dafür, dass das der Python-Standard-GUIbuilder sein soll, könnte man schon erwarten, dass das erledigt ist.

gtk schafft die 10.000 gerade noch, der gtk-TreeView wird dann aber sehr langsam (bei 2 screens Breite), scrollen ruckelt. Übrigens muss man den beim Einstieg erst einmal finden, hätte Tabellen nie unter 'Trees' gesucht.

gtk also. Die Doku ist allerdings katastrophal lückenhaft. Überall fehlen wichtige Grundsätzlichkeiten wie z.B.

- was Funktionen zurückgeben,
- wo GError definiert ist,
- dass Styles Klassen- und keine Objektmethoden sind, d.h. leicht auf alle Widgets eines Typs wirken,
- wie man rc-Dateien debugged (kann der Doku nicht einmal entnehmen, ob so etwas möglich ist)
- wie man - hat man ein Atom als Namen dafür geschaffen - denn nun ein gtk.Clipboard selbst konstruiert (die Doku behauptet, dass das möglich ist)
- dass ohne gtk.main_iteration_do() immer wieder einmal überhaupt nicht auszukommen ist, auch weil
- gtk ständig eigene Ideen durchsetzt, in welcher Reihenfolge Code auszuführen ist

usw. usw. usw. .

Es gibt aber große Vorteile.
- Die Oberflächen sehen ohne viel Zutun gut aus.
- gtk ist nicht nur GUI- sondern auch Widget-Builder.
- Die Klassenhierarchie ist sehr, sehr sinnvoll (von Überschneidungen mit den basischeren Klassen in gtk.gdk, die das Widget-Building andererseits aber erst ermöglichen, einmal abgesehen).
- Mit der pixbuf-Klasse bringt gtk.gdk tolle, sehr schnelle Grafik-Funktionen mit. Hereinmischen von Wasserzeichen, Transparenz allgemein und Skalieren von Bildern verlangsamt das Laden von Bilddateien nicht merklich.

Und übrigens: Alle, wirklich ALLE goodies von Tkinter hat gtk auch.

Macht's gut !

[Leonidas]

Tkinter hat kein Tabellen-Widget und scheidet für damit für ernsthafte db-gestützte Anwendungen aus !! Leider.

Du kannst welche nachrüsten. Musst mal schauen, ob BLT oder PMW sowas nicht mitbringen.

- dass ohne gtk.main_iteration_do() immer wieder einmal überhaupt nicht auszukommen ist, auch weil
- gtk ständig eigene Ideen durchsetzt, in welcher Reihenfolge Code auszuführen ist

Komisch, ``gtk.main()`` gekoppelt mit ``gobject.idle_add()`` und ``gobject.timeout_add()`` hat bei mir eigentlich immer alles in der richtigen Reihenfolge ausgeführt. Sogar Threads habe ich zum laufen gebracht - wobei ich aber zugebe, dass das wirklich nicht lustig war.

- gtk ist nicht nur GUI- sondern auch Widget-Builder.

GTK ist weder GUI- noch Widget-Builder Aber es hat mehrere GUI-Builder und man kann eigene Widgets schreiben. Geht aber mit Tkinter auch.

Und übrigens: Alle, wirklich ALLE goodies von Tkinter hat gtk auch.

Tkinters Canvas ist besser, wenn man mit Vektorgrafik arbeiten will. Sowas würde mich in GTK+ freuen zu sehen.

[joost]

Du kannst welche nachrüsten. Musst mal schauen, ob BLT oder PMW sowas nicht mitbringen.

PMW habe ich mal gesehen - schwere Enttäuschung, wobei ich nicht mehr genau weiß, ob es mir damals um ein Tabellen-Widget ging. Scheidet aber jedenfalls aus. TiX auch. Und sowieso, das mit dem tcl-Interpreter disqualifiziert TKinter in meinen Augen.

Du sprichst mit einem Außenseiter. Ich betrachte 90% aller Software als Schrott, 9% als brauchbar und 1% als gut. Zu letzterem gehört für mich sqlite, X11, wahrscheinlich der Python-Kern (aber wirklich nur der Kern), tex (wenn ich es auch nicht benutze), wahrscheinlich apsw (scheint mit besser als pysqlite zu sein). Ich interessiere mich für clean. Und ich will jeden Umgang mit Schrott möglichst vermeiden, vor allem auch velaltendes Wissen. Ich lerne sehr gerne, aber will das Gelernte nicht vergessen müssen. Für Linux hatte ich mich immerhin schon bei Version 0.99 entschieden, programmiere im Augenblick aber ausschließlich fremde Hardware.

Wäre ich nicht immer noch bei der idle, würde ich TKinter sogar von der Festplatte verbannen - sind ja immerhin MB.

[Leonidas]

Ich betrachte 90% aller Software als Schrott, 9% als brauchbar und 1% als gut. Zu letzterem gehört für mich sqlite, X11, wahrscheinlich der Python-Kern (aber wirklich nur der Kern), tex (wenn ich es auch nicht benutze), wahrscheinlich apsw (scheint mit besser als pysqlite zu sein). Ich interessiere mich für clean. Und ich will jeden Umgang mit Schrott möglichst vermeiden, vor allem auch velaltendes Wissen. Ich lerne sehr gerne, aber will das Gelernte nicht vergessen müssen. Für Linux hatte ich mich immerhin schon bei Version 0.99 entschieden

APSW ist was ganz anderes als pysqlite. Ja, hat auch "irgendwas mit SQLite" zu tun, ist aber ein dünner Layer um die SQLite API und kein DB-API 2 kompatibles Modul.

Wäre ich nicht immer noch bei der idle, würde ich TKinter sogar von der Festplatte verbannen - sind ja immerhin MB.

Ich habe kein Tkinter installiert - weil ich auch IDLE nicht mag. IDLE macht zu viele Probleme und kann sowieso nicht das was ich von meinem Editor fordere.

[joost]

Zu GTK2 (wo kommt die '2' denn eigentlich her ?)

Ich arbeite zZ. damit an einem 5000-Zeilen-Projekt und wollte es dafür lernen - inzwischen muss ich fast sagen, 'musste es lernen'.

Einfach ist gtk überhaupt nicht - es ist typische GNU-Software wie bash und make. Beispiel: Ich bringe immer wieder noch die Funktionen von gtk.Window (Toplevel), gtk.Widget und gtk.gdk.Window (Attribut der nicht window-losen widgets - gtk.Label z.B. ist window-los) durcheinander und habe mir deshalb neulich nur einmal die Liste der Funktionen, Attribute und Properties von Widget (und das ist nur die Basisklasse) ausgedruckt: 5 Seiten (quer). Die Klassenhierarchie ist schon in Ordnung, gerade z.B. die in der obigen Klammer genannten window-losen Widgets sind eine gute Idee.

Die Doku muss wohl Tausende von Seiten umfassen und scheint sehr weitgehend automatisiert aus der Doku für C-gtk erstellt zu werden. Man stößt immer wieder auf schwere Lücken. Außerdem ist die Terminologie z.T. eigenwillig, das Widget zur Darstellung von Tabellen heißt TreeView, es kann eben auch das, nämlich Tabellenzeilen hierarchisch ordnen und - nach Leveln kontrollierbar - ein- und ausklappen. Trotzdem werden 90% aller existierenden verwendeten TreeViews wohl Tabellen darstellen, deshalb ist der Name verschroben. border-width steuert nicht das, was normale Menschen unter Border verstehen (und die scheint immer auf 2 Pixel Breite fixiert zu sein, hab noch nicht herausbekommen, ob man an diese Eigenschaft irgendwie herankommt, brauche es aber bisher auch nicht) sondern die Breite eines berandenden Teils des Backgrounds.

Beispiel für eine dicke Lücke in der Doku: gtk.Widget ist nicht die Haupt-Basisklasse, das ist gobject.GObject. Überhaupt ist das gobject-Modul (wird eigens importiert) auf Dauer unverzichtbar. So wird vielleicht nach einiger Einarbeitung selbstverständlich, dass die einzige Exception-Klasse GError dort zu suchen ist. Die Doku sagt einem das aber nicht (besonders nicht das Tutorial, das kann man gleich vergessen), und ich brauchte damals ungefähr eine Stunde, um darauf zu kommen.

gtk ist aber sehr mächtig, die pixbuf-Klasse großartig und ich bleibe erst einmal dabei. Eines meiner Traumprojekte ware, eine DoD-Tabelle (draw-on-demand - Rendern, auch in den Hintergrundbuffer - erst auf Scrollbar-Anforderung) für db-Zwecke zu schreiben. gtk.TreeView ist wesentlich langsamer als nötig.

[joost]

Sorry, ich sehe gerade: ich habe hier geflooded, bzw. sehr viel von oben wiederholt. Las nur gerade zum ersten Mal die Frage von gerold wirklich und wollte halt darauf antworten.

[Leonidas]

Zu GTK2 (wo kommt die '2' denn eigentlich her ?)

Von der Version: GTK+ 2.x, aber GTK2+ oder GTK+2 sieht seltsam aus.

[pyStyler]

von wegen Tkinter langsam.
Hier deine 10 000 Einträge in weniger als 3 Sekunden.

http://paste.pocoo.org/show/1463/

edit: link korrigiert

[joost]

Ne,

geht nur so schnell, weil Deine Zeilen alle gleich sind. Habe hier die kommentierte Zeile geändert und das ganze gerade in der idle gestartet. Das tk-Fenster ist noch immer nicht zu sehen. Das tk-Fenster erscheint dann nach etwa 5 Minuten (und was weiß, was wäre, wenn noch mehr Unterschiede wie aus einer echten db darin wären, dazu mit 10 Spalten oder so).

Code: Alles auswählen

class Master(object):
    def __init__(self):
        self.dataBase = shelve.open(DATABASE)
        
        for xv in range(100):
            self.prdk = '0123145'+str(xv)  # geändert
            self.entry = ['Leckerschocko', '1']
            print 'Hallo'
            self.dataBase[self.prdk] = self.entry
            print self.dataBase

[pyStyler]

Ne,

geht nur so schnell, weil Deine Zeilen alle gleich sind. Habe hier die kommentierte Zeile geändert und das ganze gerade in der idle gestartet. Das tk-Fenster ist noch immer nicht zu sehen. Das tk-Fenster erscheint dann nach etwa 5 Minuten (und was weiß, was wäre, wenn noch mehr Unterschiede wie aus einer echten db darin wären, dazu mit 10 Spalten oder so).

Code: Alles auswählen

class Master(object):
    def __init__(self):
        self.dataBase = shelve.open(DATABASE)
        
        for xv in range(100):
            self.prdk = '0123145'+str(xv)  # geändert
            self.entry = ['Leckerschocko', '1']
            print 'Hallo'
            self.dataBase[self.prdk] = self.entry
            print self.dataBase

Na super du hast es echt drauf! Schau deinen Code noch einmal an und sag was du falsch gemacht hast.

[pyStyler]

für Zweifler
http://paste.pocoo.org/show/1465/

[joost]

Ja, da habe ich Unsinn getrieben, hab ja nur Schlüssel verändert. Wollte schnell reagieren (und ich verbringe den Abend nicht nur hiermit) und habe Deinen Code flüchtiger gelesen, als Dein engagiertes Eintreten für Dein GUI verdient - DAFÜR sorry. Und - ja, ich hab einiges drauf.
Wohin ich es ändern wollte, war auf dies:

Code: Alles auswählen

       def getDatabase(self):
            db = shelve.open(DATABASE)
            self.mlt.delete(0, END)
            
            for i in range(10000):
                for x in db.keys():
                    ( B, M ) = db[x]
                    self.mlt.insert(END, (x, B+str(i), M))
            db.close()

Und von 3 Sekunden kann keine Rede mehr sein, warte jetzt schon einige Minuten auf das tk-Fenster. Ich werde meine Behauptungen über TKinter schon noch ein wenig verteidigen. Ich mochte TKinter wirklich und hatte eine Tabelle fertig (neues Steuerelement), die nur auf Anforderung rendert (und sonst eben auch im Hintergrund nicht, die Zahl der Zeilen ist dann ganz egal und kann auch tatsächlich unendlich sein). Unter Verwendung einer dll von F.Lundh für ein Projekt, mit dem er wohl schon 2001 begonnen hatte und das ruht oder tot ist. Nun müssen es wohl schon 10 Minuten sein - ach, da kommt das Fenster gerade und ich kann all dies erst einmal abschließen.

[joost]

Der Fairness halber: Mit Labels in ein Frame hat TKinter in einem 3-Spalten-Beispiel am heutigen 01.05.2007 tatsächlich nur wenige Sekunden für 10.000 (sehr einfache) Zeilen (in anonyme Labels) geschafft. In dem von mir in anderen Beiträgen referenzierten benching hatte ich -glaube ich- benannte Labels erzeugt (in einer Schleife mit Hilfe von exec(), damit auch in eine Liste). Vielleicht auch Performance-wirksame Fehler gemacht.

Ist für mich inzwischen akademisch. Ab einer bestimmten Größe wären Tabellen optimal, die immer nur einen visuellen widget-Inhalt rendern und sonst gar nichts, auch nicht in Speicher-Bitmaps oder -pixmaps oder -pixbufs. Oder über die Breite komplett in einen Speicher-Hintergrund und dann in das widget clippen. Unter den Lösungen darunter ist das gtk.TreeView bestimmt nicht die schlechteste.

Weiterhin bleibt richtig, dass TKinter keine Tabelle hat. Das Beispiel mit den Labels in das Frame hätte noch viel, viel Programmierarbeit nötig, bis man eine brauchbare Tabelle hätte. Diese Arbeit würde ich persönlich lieber darein stecken, gtk mit C zu einer Draw-on-Demand-Tabelle zu verhelfen, auch wenn das ein deutlich umfangreicheres Projekt wäre.

[gummibaerchen]

gtk schafft die 10.000 gerade noch, der gtk-TreeView wird dann aber sehr langsam (bei 2 screens Breite), scrollen ruckelt. Übrigens muss man den beim Einstieg erst einmal finden, hätte Tabellen nie unter 'Trees' gesucht.

Ein echtes Sheet-Widget ist schon viel diskutiert, doch mittlerweile hat das noch keiner richtig umgesetzt.

Gnumeric hat sich ein eigenes geschrieben, was sehr schnell ist.

Schade, dass es sowas nicht in GTK+ direkt gibt...

[joost]

Gnumeric ist ja sehr interessant (allein schon für .xls-Imports). Habe die Installation nach Download aber erst einmal abgebrochen, als ich sah, dass 65MB - mehr als das Doppelte meiner gesamten gtk-Installation - belegt werden sollen. Ist aber nicht das Ende, will ich nur nicht auf die Schnelle machen. Dank !
___________________
Schlechte Software ist schlimmer als keine Software

[fred.reichbier]

Ich benutze wxPython, weil mir die Dokumentation und die Demo-Applikation auf Anhieb gefallen haben. Manchmal zwar ein bisschen umständlich, aber dafür nativen Look auf Windows und Linux Wax sieht auch noch ziemlich interessant aus, aber da passiert anscheinend nichts mehr.
GTK gefällt mir unter Windows einfach nicht. FLTK sieht meiner Meinung nach noch ganz OK unter Windows aus, die Beispiele sehen leicht verständlich aus, aber pyFLTK scheint auch eingeschlafen zu sein wie ich das mitkriege.