Python Toolkit

[ProgChild]

Wir hatten hier neulich mal eine kleine Diskusstion über ein neues Python Toolkit.

Ich hab mir dazu mal ein paar gedanken gemacht... Um das natürlich "Look and Feel" der Betriebssysteme zu erreichen sollte man unter Windows die WinAPI und unter Unix GTK+ benutzen...

Also man sollte die Widgets in C schreiben, da man dann direkt auf die WinAPI und auf GTK+ zugreifen kann. Die Layouter wie, z.B. Table können dann in Python geschrieben werden.

Ich denke, dass das vorallem eine Fleißarbeit ist... Allerdings sollte man das schon vorher ein bisschen genauer planen, damit man sich die Arbeit nicht zweimal macht. Hier ist also mal so ein grobe Skizze:

Code: Alles auswählen

Klassen Hirarchie

Widget
|-Button
|-RadioButton
|-CheckButton
|-Edit
|-MultilineEdit
|-Label
|-ProgressBar
|-List
|-TreeView
|-Toolbar
|-Menu
|-PopupMenu
|-Image
|-DrawingArea
|-(OpenGLView)
|
|-Container
  |-Window
  |-Table
  |-VBox
  |-HBox

Widget Funktionen:
	get_size_request()
		Gibt die Größe zurück, die das Widget gerne hätte
		
	set_position( left, top, width, height )
		Setzt die Größe des Widgets

	set_visible( visible )
	get_visible( visible )
		Sichtbar, oder nicht...

Container Funktionen:
	Unterschiedliche Funktionen zum hinzufügen von Widgets
	und Containern
	z.B. add()

	layout()
		Ordnet alle Kindelemente an
		
		Fragt erst von allen Kinder mit der Funktion
		get_size_request() ab, wie viel Platz sie benötigen.
		Wenn kein Aufruf von set_position, erfolgt war,
		ändert es seine Größe so, dass alle Kinder genug
		Platz haben. Dann Teilt es mit der Funktion
		set_position den Kinden mit, wie viel Platz sie
		haben und ruft in allen Kinden die Funktion Layout
		auf, wenn es sich um einen Container handelt.

Ich würde mich über kommentare freuen

Ich bin mir zwar noch nicht sicher, ob ich das durchziehen kann, aber vielleicht wird es ja doch etwas...

[Joghurt]

Um das natürlich "Look and Feel" der Betriebssysteme zu erreichen sollte man unter Windows die WinAPI und unter Unix GTK+ benutzen...

Das alles macht WxWidgets, das Python-Interface heißt wxPython. Was gefällt dir daran nicht?

[jens]

wxPython ich mächtig, kompliziert, buggy und schlecht dokumentiert...

@ProgChild: An die WinAPI kommt man doch auch über Mark Hammond's Win32all , oder? Dann könnte man es auch direkt in Python und nicht in C schreiben, was wieder viel interessanter ist!
Oder würde das ganze zu langsam werden?

[Leonidas]

wxPython ich mächtig, kompliziert, buggy und schlecht dokumentiert...

Mächtig: Ja, es kann einiges.
Kompliziert: Schon mal so wxWrapper wie Wax angeschaut?
Buggy: Ja, es hat schon ein paar macken. Aber sowas lässt sich sicher mit C-Kenntnissen fixen und als Patch einbauen.
Schlecht Dokumentiert: Es gibt das Wiki und auch wenn du ein Tutorial schreibst (z.B wie das PyGTK Tutorial) wird dich keiner schimpfen.

@ProgChild: An die WinAPI kommt man doch auch über Mark Hammond's Win32all , oder? Dann könnte man es auch direkt in Python und nicht in C schreiben, was wieder viel interessanter ist!
Oder würde das ganze zu langsam werden?

Ja, das geht mit pywin32, damit kannst du MFC-Oberflächen schreiben.

Es ist weniger eine Fleissarbeit, eher so in der Richtung: ich tausche mein Leben gegen Python, GCC/MSVC usw.

Ich würde dir eher empfehlen in einem bestehenden Projekt mitzumachen, wenn du sowas machen willst, wie zum Beispiel direkt wxPython, Wax, anygui & Co.

[ProgChild]

Das alles macht WxWidgets, das Python-Interface heißt wxPython. Was gefällt dir daran nicht?

Mir gefällt der Stiel von wxWidgets nicht. Außerdem scheinen die Entwickler zu versuchern Windows unter den anderen Plattformen nachzubauen. Als Beispiel: Sie haben für GTK+ den Windows Dateidialog nachgebaut, statt den GTK+ Dateidialog zu nehmen.

@ProgChild: An die WinAPI kommt man doch auch über Mark Hammond's Win32all , oder?

Und für GTK+ gibt es auch einen Wrapper für Python. Ich bin nur kein Freund von vielen Abhängigkeiten...

Oder würde das ganze zu langsam werden?

Ich denke, dass das nicht zu langsam werden würde...

Ich würde dir eher empfehlen in einem bestehenden Projekt mitzumachen, wenn du sowas machen willst, wie zum Beispiel direkt wxPython, Wax, anygui & Co.

Ich habe diese Idee nicht, weil ich unbedingt mein eigenes Projekt machen will, sondern weil mir die Toolkits dich ich kenne, nicht gefallen... Was mir an wxPython nicht gefällt, das hab ich ja schon geschrieben. AnyGUI soll schon länger tod sein. QT kann ich wohl auch vergessen es sei denn, ich würde umziehen und mich bei Trolltech bewerben...

Mir gefällt PyGTK sehr gut, allerdings ist das nicht besonders Plattformunabhängig... Mit WIMP sehen die Anwendungen zwar ziemlich "Windows Like" unter Windows aus, aber das wahre ist das nicht... Es ist also mehr der mangel an einem guten Toolkit, der hier meine Phantasie anregt...

[Leonidas]

QT kann ich wohl auch vergessen es sei denn, ich würde umziehen und mich bei Trolltech bewerben...

Wieso das? Willst du etwa Programme nicht GPL lizensieren?

Was die Windows-likeheit angeht, weiß ich ja nicht wie es mit Qt4 aussieht, aber mit Qt3 war das Look-and-Feel auch nicht 100%ig.

Sie haben für GTK+ den Windows Dateidialog nachgebaut, statt den GTK+ Dateidialog zu nehmen.

Vielleicht weil der GtkFileChooser-Dialog erst in Version 2.4.0 hinzugekommen ist und sie kompatibel mit GTK+ 2.0 bleiben wollen? Ich weiß es nicht, wenn du willst kannst du mal in der Mailingliste fragen.

AnyGUI soll schon länger tod sein.

Ja und? Dafür hat man immerhin schon Code von dem man starten kann und es ist auch schon etwas bekannter (auch wenn es die besten Tage tatsächlich schon hinter sich hat).

[ProgChild]

QT kann ich wohl auch vergessen es sei denn, ich würde umziehen und mich bei Trolltech bewerben...

Wieso das? Willst du etwa Programme nicht GPL lizensieren?

Nöö, will ich nicht... Weil ich sonst die Leute, die mein Toolkit benutzen würden, ihren Sourcecode offen legen müssten. Ich würde ehr LGPL, wenn nicht sogar BSD-Licence bevorzugen...

Vielleicht weil der GtkFileChooser-Dialog erst in Version 2.4.0 hinzugekommen ist und sie kompatibel mit GTK+ 2.0 bleiben wollen? Ich weiß es nicht, wenn du willst kannst du mal in der Mailingliste fragen.

Davor gab es den FileSelection Dialog. Den haben die ja von Anfang an nicht genommen. Aber das ist auch ehr eine Kleinigkeit. wxWidgets, ist mir einfach zu viel Windows und zu viel MFC-Like...

AnyGUI soll schon länger tod sein.

Ja und? Dafür hat man immerhin schon Code von dem man starten kann und es ist auch schon etwas bekannter (auch wenn es die besten Tage tatsächlich schon hinter sich hat).[/quote]

Nur mitmachen kann ich da wohl nicht mehr, weil keiner mehr da ist... Ich würde da wohl auch alleine stehen. Was bei QT ebenfalls der fall sein würde...

Allerdings überlege ich doch, wie ich mehr in Python als in C schreiben kann...

[Mr_Snede]

Hier mal meine Ideen.
Wenn was ganz neues entstehen soll bin ich dafür das nur in Python zu machen (wenn es denn geht) Da hatte ich mal ein oder zwei Projekte / Prinzipstudien gefunden - mal schauen, ob ich die noch mal wiederfinde.

Für mich solte es möglichst klein, keine anderen Abhängigkeiten, einfach zu Programmieren und gut dokumentiert sein.
Interessant fände ich, wenn man einige Widgets auch im Textmode für Win + Lin anbieten würde. Also dass ich (bei begrenzter Widgetauswahl) ein Programm eben im Textmodus oder auf einer Grafischenoberfläche starten kann.

Bei der Dokumentation bestehende Projekte kann man auch mithelfen und so dort die Situation verbessen.

Ansonsten denke ich kann man bestehende GUI Toolkits benutzen und einen Wrapper drumschreiben und Dokumentieren. Zwei Kandidaten sind fltk[1] und Fox [2]. Für fltk1.x gibt es einen Wrapper, der von einer einzelnen Person (soviel ich weiß) betreut wird. Leider scheint es für Fox keine nutzbaren python-bindings zu geben.


[1] http://www.fltk.org/
[2] http://www.fox-toolkit.org/

[henning]

Code: Alles auswählen

Klassen Hirarchie

Widget
|-Button
|-RadioButton
|-CheckButton
|-Edit
|-MultilineEdit
|-Label
|-ProgressBar
|-List
|-TreeView
|-Toolbar
|-Menu
|-PopupMenu
|-Image
|-DrawingArea
|-(OpenGLView)
|
|-Container
  |-Window
  |-Table
  |-VBox
  |-HBox

Ich fänds noch cooler, wenn das UI so allgemein gehalten wird, dass
man auch ne konsolen-anwendung (OHNE curses) draus machen kann,
aber wahrscheinlich ist diese Idee zu abgefahren, da man dann zu viele features der speziellen umsetzungen nicht nutzen kann.

Mal etwas ernster: Was ist mit ncurses support? Daswar ja z.B. einer der grundsätzlichen anreize, das rad neu zu erfinden... was bedeutet eine DrawingArea oder ein Image in ncurses?

[Mr_Snede]

Ich fänds noch cooler, wenn das UI so allgemein gehalten wird, dass
man auch ne konsolen-anwendung (OHNE curses) draus machen kann,
aber wahrscheinlich ist diese Idee zu abgefahren, da man dann zu viele features der speziellen umsetzungen nicht nutzen kann.

Genau an sowas dachte ich. Mir ist aber klar, dass man nicht jedes Widget auch für den Textmodus nachstellen kann / muss.
Ich denke da sollten Knöpfe, sowas wie tkSimpleDialog, ein Editor, eine Listbox, Eingabefeld und ein Datei/Ordner Auswahl/Speicher - Dialog reichen.
Ob man auch einen Layoutmanager wie pack aus tk implementiren kann weiß ich nicht, das wär aber der Oberhammer :-))

cu Sebastian

[henning]

Ich denke das Hauptproblem ist, dass man jederzeit sauber zwischen der Struktur und der Anordnung unterscheiden muss.
Im "reinen" Textmodus macht es kaum Sinn, anzugeben, ob Eingabefelder nebeneinander oder übereinander stehen, da der user eh vielleicht macheinander nach allen Eingaben gefragt wird.
Vielleicht wird er auch vorher gefragt, welches Feld er bearbeiten möchte.

Man könnte ja z.B. den Begriff der Gruppierung von Elementen einfügen, der einfach erstmal nur andeutet, dass diese Elemente zusammenghören.
Dann könnte ich mir noch "hints" vorstellen, also Hinweise, die vielleicht über keyowrds übergeben werden und die UI bitten die Elemente nach Möglichkeit übereinander oder nebeneinander anzuordnen.

Ein weiteres Beispiel wäre für mich ein Dialog (analog zu dem bekannten Begriff in GUIs): Ein Dialog besteht aus einer Gruppe (die weitere Gruppen enthalten kann?) und einer oder mehreren Aktionen.
Aktionen sind Sachen, die man jederzeit machen kann und für den ganzen Dialog gelten (z.B. Abbrechen, Änderungen übernehmen, "Ok"), also das was bei den GUIs üblicherweise mit Buttons am unteren Rand signalisiert wird.

Wenn man das mal ein bisschen weiterdenkt, ergibt sich daraus eine sehr mächtige und universelle Art, UIs zu beschreiben, im Hinterkopf grübel ich gerade darüber nach, inwiefern man genau das als Ersatz für z.B. HTML-Seiten benutzen könnte um Websiten darzustellen (mit speziellem Browser versteht sich)

[jens]

Gerade gefunden: http://www.cosc.canterbury.ac.nz/~greg/python_gui/ ist vielleicht das passende...