Von der Version: GTK+ 2.x, aber GTK2+ oder GTK+2 sieht seltsam aus.joost hat geschrieben:Zu GTK2 (wo kommt die '2' denn eigentlich her ?)
Welche GUI-Toolkits verwendet ihr?
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
von wegen Tkinter langsam.
Hier deine 10 000 Einträge in weniger als 3 Sekunden.
http://paste.pocoo.org/show/1463/
edit: link korrigiert
Hier deine 10 000 Einträge in weniger als 3 Sekunden.
http://paste.pocoo.org/show/1463/
edit: link korrigiert
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).
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.joost hat geschrieben: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
für Zweifler
http://paste.pocoo.org/show/1465/
http://paste.pocoo.org/show/1465/
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:
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.
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()
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.
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.
-
- User
- Beiträge: 51
- Registriert: Samstag 7. Oktober 2006, 15:13
Ein echtes Sheet-Widget ist schon viel diskutiert, doch mittlerweile hat das noch keiner richtig umgesetzt.joost hat geschrieben: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.
Gnumeric hat sich ein eigenes geschrieben, was sehr schnell ist.
Schade, dass es sowas nicht in GTK+ direkt gibt...
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
___________________
Schlechte Software ist schlimmer als keine Software
-
- User
- Beiträge: 155
- Registriert: Freitag 29. Dezember 2006, 18:27
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.
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.
- daemonTutorials
- User
- Beiträge: 171
- Registriert: Sonntag 6. Februar 2011, 12:06
- Kontaktdaten:
Ist auch meine Meinung.Dookie hat geschrieben:Plattformunabhängig -> Tkinter
für UNIX/Linux -> gtk
an QT gefällt imr die Linzenzpolitik nicht.
und wxpython is mir zu lahm.
Gruß
Dookie
Auch wenn viel sagen, dass Tkinter für große Projekte nicht toll ist, ich nutze es.
LG Maik
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Dookie hat geschrieben: an QT gefällt imr die Linzenzpolitik nicht.
Das ist halt die Folge, wenn man einen >4 Jahre alten Thread so mir nichts dir nichts wieder belebt...daemonTutorials hat geschrieben: Ist auch meine Meinung.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Welches Problem hast du mit der Lizenz von QT, dass du dafür längst in Frieden ruhende Threads wieder ausbuddeln musst? Was willst du denn noch mehr als GPLv3 und LGPL2.1?daemonTutorials hat geschrieben:Ist auch meine Meinung.Dookie hat geschrieben:[...]
an QT gefällt imr die Linzenzpolitik nicht.