GUI-Toolkit in purem Python

[snafu]

Hi,

man könnte doch mal ein Toolkit anfangen, dass auf python-xlib Basis geschrieben ist und damit 100% Python wäre. Ich fände es einfach cool, wenn es mehr Python-native Bibliotheken gäbe als immer "nur" Bindings. Weiß jemand, ob es so ein Projekt schon gibt oder müsste man bei Null anfangen?

[tordmor]

Nicht ganz native, da es auf systemspezifischen toolkits basiert, aber ein Schritt in die Richtung: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

[Rebecca]

Als Anwender finde ich es eigentlich gut, wenn die Programme die ich verwende, egal in welcher Sprache geschrieben, mein Lieblings-Toolkit nutzen. Dann stimmt das Look&Feel...

[snafu]

Nicht ganz native, da es auf systemspezifischen toolkits basiert, aber ein Schritt in die Richtung: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

Das finde ich überhaupt nicht nativ. Das ist mehr oder weniger ein Wrapper für andere Wrapper, der die Funktionalität des jeweiligen Toolkits stark kastriert. Mir erschließt sich auch der Sinn dieses Projektes nicht so ganz, da zumindest Gtk ja bereits plattformunabhängig ist. Ich meinte halt etwas, wo ich Tracebacks hätte, die notfalls bis in den Lowlevel-Bereich des Problems reichen und wo ich die Funktionalität problemlos mit Tools wie IPython einsehen kann. Ich finde es halt schade, dass Python in dem Bereich nichts "eigenes" hat.

[Defnull]

Das macht nicht immer Sinn. Spätestens bei der Render-Engine für canvas Elemente (die eigentlich jedes gui tk können sollte) ist Python als Scriptsprache schlicht zu langsam.

[snafu]

Gut beim Rendering müsste man dann Abstriche machen und den Kram von Cairo + Pango erledigen lassen. Bleibt aber trotzdem noch einiges, das man in Python implementieren könnte. Und in ferner Zukunft ist Python vielleicht auch mal schnell genug für's Rendering...

[Defnull]

Das wird denke ich nie der Fall sein, da Python-Scripte niemals direkten und unmittelbaren Zugriff auf den Speicher bekommen werden und niemals nativen Maschinencode generieren und optimieren können (was beides für hoch optimierte mathematische Algorithmen zwingend notwendig ist). Scriptsprachen haben IMMER einen Overhead durch die Laufzeitumgebung.

Python ist (und bleibt) nun mal eine Script-Sprache. Und das ist auch gut so Choose the right tool.

[BlackJack]

@Defnull: Sag niemals nie. An "rohen" Speicher kommt man mittels `ctypes` und für den Maschinencode könnte man über `ctypes` sicher die GNU lightning-Bibliothek anbinden.

Ausserdem könnte man erst mal alles in Python schreiben und die kritischen Teile dann auf Cython umschreiben.

[Defnull]

Wo wir dann wieder bei C-Modulen wären.

[DasIch]

Man könnte doch durchaus erstmal alles in Python schreiben und dann die Teile die zuviel Zeit verbrauchen durch C Module ersetzen.

[snafu]

Naja, hab mir gerade mal ein paar Beispiele von der Python-Implementierung der Xlib angeguckt. Man müsste halt einige Dinge auf sehr niedriger Ebene implementieren und auch erstmal die Abläufe besser verstehen, was bestimmt keinen allzu großen Spass macht.

Und der große Aha-Effekt wird wohl auch kaum eintreten, da die eigenen Ansätze vermutlich gerade so an FLTK-Niveau rankämen. Und wer will das dann schon nutzen, nur weil es in Python ist aber dafür sehr bescheiden aussieht...

[sma]

Anfang der 70er Jahre kamen einige Ingenieure im Xerox Palo-Alto Research Center (PARC) auf die Idee, dass man einen Computer mit einem Bitraster-Bildschirm bauen könnte, bei dem man jeden Pixel einzeln frei programmieren könnte. Dan Ingalls erfand den BitBlt-Algorithmus, eine einzelne (zugegeben komplex parametrisierbare) Operation, mit der man alles von Bildschirm löschen, Teile kopieren, invertieren, scrollen, Linien zeichnen bis hin zur Ausgabe einer nicht-proportionalen Schrift realisieren konnte.

Anfang der 80er Jahre hatte der Amiga einen Spezialchip namens Blitter, der einiger dieser Aufgaben übernehmen konnte und so den 8 MHz 68k-Prozessor entlasten konnte. Denn auch der Amiga hatte die bis dahin unübliche Bitrastergrafik. IBM PCs und frühere Homecomputer hatten einfache 40x25 oder 80x25 Zeichendarstellung wie ein Terminal.

Smalltalk-72, -76 und -80 waren alle um Größenordnungen langsamer als heutige PCs, selbst wenn sie Python ausführen. Daher sollte es prinzipiell kein Problem sein, die gesamte Grafik Pixel für Pixel in Python zu zeichnen. X ist ja bereits eine Abstraktion, die einem das Ziehen von Linien oder die Ausgabe von Text abnimmt. Smalltalk hat dies alles (zugegeben nur in Schwarzweiß) selbst gezeichnet. Die ersten Squeak-Versionen aus der Mitte der 90er Jahre zeigten recht schön, wie das damals aussah und Squeak enthielt eine spezielle BitBlt-Version für farbige Darstellung, komplett in Smalltalk geschrieben und dann von einem Smalltalk-nach-C-Übersetzer in C übersetzt und dann per GCC in Maschinencode übersetzt und in die Smalltalk-VM integriert.

Stefan

[snafu]

Ich hab mal versucht, ein bißchen Struktur reinzubringen und biete nun ein Fenster-Widget mit ganzen 4 Parametern.

Code: Alles auswählen

import pptk

if __name__ == '__main__':
    app = pptk.Application()
    window = pptk.Window(400, 300, 'Just testing', __file__)
    app.add(window)
    app.run()

pptk.py

EDIT: Da eine Applikation erstmal nur ein Fenster haben soll, hab ich ein paar kleine Änderungen vorgenommen, bei denen auch die Typprüfung rausgeschmissen wurde:

Code: Alles auswählen

import pptk

if __name__ == '__main__':
    window = pptk.Window(400, 300, 'Just testing', __file__)
    app = pptk.Application(window)
    app.run()

pptk.py

EDIT2:

Jetzt auch mit Hintergrundfarbe.

Code: Alles auswählen

import pptk

if __name__ == '__main__':
    window = pptk.Window(400, 300, 'Just testing', __file__, 'grey')
    app = pptk.Application(window)
    app.run()

pptk.py

[snafu]

Ich will als nächstes Schriftfelder einbauen. Anhand eines Beispiels (nach "open_font" suchen) hab ich herausgefunden, dass man die Übergabe wohl in diesem Format machen muss:

Code: Alles auswählen

font = '-adobe-times-medium-r-normal-*-90-*-*-*-*-*-iso8859-1'
[...]
self.display.open_font(font)

Wie nennt man dieses Format? Das würde mir die weitere Suche zur Bedeutung der Angaben vereinfachen. Vielleicht hat auch jemand einen guten Link zum Thema?

EDIT: Aha, hab's gefunden: XLFD

[veers]

So ein Projekt würde mMn vor allem auf Basis von OpenGL Sinn machen. Zum einen bringt OpenGL viele Mechanismen die es möglich machen auch mit reinem Python schnellen Code zu schreiben (DisplayLists, VertextBuffer, Shader usw), zum anderen besteht da ein echter bedarf. Wie Rebecca schon sage, bei einer normalen Desktop Anwendung bin ich froh wenn sie GTK oder QT verwendet und halbwegs ins ganze passt. Bei einer "Multimedia Anwendung" finde ich es hingegen durchaus angemessen ein etwas verspielteres GUI zu haben. Und da gibt es soweit ich weiss noch keine ausgereifte Lösung.

Defnull,
Ich behaupte das es mit OpenGL möglich wäre das ganze in reinem Python zu realisieren. Ob es dann Sinnvoll ist, ist eine andere Frage. Aber ich denke die Antwort darauf bekommt Mann erst nach dem die Tat getan ist.

Cheers,
Jonas

[jens]

Wie ist eigentlich die GUI in blender gelöst?

[Rebecca]

Eigene Entwicklung, aber Blender ist nicht in Python programmiert.

[Dauerbaustelle]

Darf ich hier mal ganz heimlich für ooxcb, einem objektorientierten Xlib-Binding werben... ;)

[snafu]

Ja, gut. Die API ist dort aber nun mal sehr Xlib-spezifisch. Bei einem Fenstermanager würde das IMHO anders aussehen. Außerdem gibt es ja auch schon The Python X Library, welches ebenfalls pures Python ist.

[Dauerbaustelle]

Ja, gut. Die API ist dort aber nun mal sehr Xlib-spezifisch. Bei einem Fenstermanager würde das IMHO anders aussehen

Wie meinen?