Hallo Forum Freunde
Ich arbeite nur mit TKINTER. Es ist
genügend Informationsmaterial in
Form von Büchern und auf dem Internet
als PDF- & HTM-Doc's verfügbar. Wird
auch in unserem Forum sehr gut unterstützt.
Einfach portierbar auf andere OS.Plattformen.
Läuft Stabil und für mich doch überraschen
schnell.
Als Ergänzung zu Tkinter verwende ich
PMW 1.2 und PIL 1.14 die auch gut
dokumentiert sind und stabil laufen.
Setze diese hauptsächlich bei
komplexeren Programmen ein.
Fehlende Widgets können mit dieser
Ausrüstung selber erstellt werden.
Gruss wuf
Welche GUI-Toolkits verwendet ihr?
-
- User
- Beiträge: 52
- Registriert: Montag 19. Januar 2004, 22:19
- Wohnort: Vor meinem Computer
- Kontaktdaten:
Ich benutz nur wxPython, aus schulischen Gründen, da programmieren wir halt nur in wxPython und ich würde mir ja ein bein stellen wenn ich mit was anderem programmiere.
ich weiss nicht was die leute gegen die docu von wxPython auszusetzen haben, alle nötigen informationen sind enthalten und das beste an wxPython ist das mitgelieferte demo programm mit unendlich vielen beispielen wo man sich ruhig sachen auskopieren kann.
und wenn ich noch fragen habe muss ich ja nur Christropy hier ausm forum fragen
ich werde bei wxPython bleiben weil ich mich da gerade so eingelebt habe und es mir recht gut gefällt
ich weiss nicht was die leute gegen die docu von wxPython auszusetzen haben, alle nötigen informationen sind enthalten und das beste an wxPython ist das mitgelieferte demo programm mit unendlich vielen beispielen wo man sich ruhig sachen auskopieren kann.
und wenn ich noch fragen habe muss ich ja nur Christropy hier ausm forum fragen
ich werde bei wxPython bleiben weil ich mich da gerade so eingelebt habe und es mir recht gut gefällt
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo Python-Gemeinde!
Ich bin gerade dabei, mich mit GTK2 anzufreunden.
Mit Glade kann ich recht einfach XML-Dateien machen, die die Benutzeroberfläche beschreiben. Diese kann ich mit pyGtk importieren und relativ einfach zum Leben erwecken. Mit vier Zeilen Python-Code sind alle Signale der GTK-Oberfläche mit meinem Python-Programm verbunden. Bei trivialen Änderungen an der GTK-Oberfläche mit Glade, brauche ich keine Zeile Code umschreiben. Mit dem "PyGTK 2.0 Reference Manual" an der Seite, so scheint es zumindest, kann man mit pyGTK sehr einfach Programme mit grafischer Oberfläche schreiben.
Jetzt kommen die großen Fragen :
Warum steigt GTK so schlecht ab, bei dieser Umfrage???
Was ist an wxWidgets so gut?
Jetzt kann ich noch umsteigen, da ich noch nicht so viel Zeit in GTK2 investiert habe.
Welche Probleme können mit GTK2 auf mich zu kommen?
mfg
Gerold
Ich bin gerade dabei, mich mit GTK2 anzufreunden.
Mit Glade kann ich recht einfach XML-Dateien machen, die die Benutzeroberfläche beschreiben. Diese kann ich mit pyGtk importieren und relativ einfach zum Leben erwecken. Mit vier Zeilen Python-Code sind alle Signale der GTK-Oberfläche mit meinem Python-Programm verbunden. Bei trivialen Änderungen an der GTK-Oberfläche mit Glade, brauche ich keine Zeile Code umschreiben. Mit dem "PyGTK 2.0 Reference Manual" an der Seite, so scheint es zumindest, kann man mit pyGTK sehr einfach Programme mit grafischer Oberfläche schreiben.
Jetzt kommen die großen Fragen :
Warum steigt GTK so schlecht ab, bei dieser Umfrage???
Was ist an wxWidgets so gut?
Jetzt kann ich noch umsteigen, da ich noch nicht so viel Zeit in GTK2 investiert habe.
Welche Probleme können mit GTK2 auf mich zu kommen?
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
-
- Python-Forum Veteran
- Beiträge: 2010
- Registriert: Freitag 11. Oktober 2002, 18:00
- Wohnort: Salzburg
- Kontaktdaten:
Hi gerold,
na soo schlecht schneidet GTK2 auch nicht ab, viele hier haben aber Python unter Windows laufen, und dort ist GTK2 nicht so verbreitet. Dann schreiben viele, die Linux laufen haben Ihre Programme unter KDE da ist GTK2 auch wieder nicht so beliebt, wie Bei Gnome-Usern eben QT nicht so gerne verwendet wird. Ich selber mache öfter was für Gnome und dort eben auch mit GTK2.
Für Platformunabhängigkeit bietet sich eben dann Tkinter oder WxWidgets an, wobei ich dann Tkinter den Vorzug gebe.
Gruß
Dookie
na soo schlecht schneidet GTK2 auch nicht ab, viele hier haben aber Python unter Windows laufen, und dort ist GTK2 nicht so verbreitet. Dann schreiben viele, die Linux laufen haben Ihre Programme unter KDE da ist GTK2 auch wieder nicht so beliebt, wie Bei Gnome-Usern eben QT nicht so gerne verwendet wird. Ich selber mache öfter was für Gnome und dort eben auch mit GTK2.
Für Platformunabhängigkeit bietet sich eben dann Tkinter oder WxWidgets an, wobei ich dann Tkinter den Vorzug gebe.
Gruß
Dookie
Also ehrlich gesagt bin ich so neu in Python das ich erst hier auf der suche nach einer Alternative auf Tkinter gestossen bin. Weil ich ein Tool komplett in mit wxPython erstellt habe, aber mir das (mit py2exe erstellte) Resultat zu gross ist (12Mb!?). *Ähm* habe noch nicht mal viel doco gelesen weil ich als Editor "Boa Constructer" verwendet habe .
Welches GUI-Toolkit ist denn am besten für Windows?(am kleinsten)
Welches GUI-Toolkit ist denn am besten für Windows?(am kleinsten)
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Hmm, FLTK?Olliminator hat geschrieben:Welches GUI-Toolkit ist denn am besten für Windows?(am kleinsten)
Dass es aber am besten ist, würde ich nicht sagen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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..
Ich find wxPython schoen simpel und einfach, aber trotzdem maechtig.
So long..
Ohloh | Mein Blog | Jabber: segfaulthunter@swissjabber.eu | asynchia – asynchrone Netzwerkbibliothek
In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move.
In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move.
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?
Aber was bietet sich im wirkliche grafischen Bereich?
pygame?:
import pygame
from pygame.locals import *
-> No module named locals.... lol?
wxPython?
Blender?
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Vom Überfluss an Wissen wirst du sicherlich nur profitieren.skypa hat geschrieben:Also kann ich mir Tkinter anscheinend mit ruhigen Gewissen beibringen ohne nachher Zeit vergeudet zu haben wenns um plattformunabhängige Programme geht...
Was definierst du als wirklich grafisch? Tkinter ist wirklich, echt und wahrhaftig grafisch.skypa hat geschrieben:Aber was bietet sich im wirkliche grafischen Bereich?
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.skypa hat geschrieben:import pygame
from pygame.locals import *
-> No module named locals.... lol?
Blender ist gar kein Toolkit sondern ein Modelling-Programm mit Python-Interface. Du nutzt ja auch kein AutoCAD als grafisches Toolkit für AutoLisp.skypa hat geschrieben:Blender?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- User
- Beiträge: 51
- Registriert: Samstag 7. Oktober 2006, 15:13
Naja, wohl besser Lazarus mit FreePascalpiddon hat geschrieben: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.
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.
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 !
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 !
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Du kannst welche nachrüsten. Musst mal schauen, ob BLT oder PMW sowas nicht mitbringen.joost hat geschrieben:Tkinter hat kein Tabellen-Widget und scheidet für damit für ernsthafte db-gestützte Anwendungen aus !! Leider.
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.joost hat geschrieben:- 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
GTK ist weder GUI- noch Widget-Builder Aber es hat mehrere GUI-Builder und man kann eigene Widgets schreiben. Geht aber mit Tkinter auch.joost hat geschrieben:- gtk ist nicht nur GUI- sondern auch Widget-Builder.
Tkinters Canvas ist besser, wenn man mit Vektorgrafik arbeiten will. Sowas würde mich in GTK+ freuen zu sehen.joost hat geschrieben:Und übrigens: Alle, wirklich ALLE goodies von Tkinter hat gtk auch.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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 kannst welche nachrüsten. Musst mal schauen, ob BLT oder PMW sowas nicht mitbringen.
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.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.joost hat geschrieben: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
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 hat geschrieben:Wäre ich nicht immer noch bei der idle, würde ich TKinter sogar von der Festplatte verbannen - sind ja immerhin MB.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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.
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.