Hallo erstmal! (Mein erster Beitrag)
Ich habe mir main mein eingenes TUI-Toolkit gebastelt.
http://pastebin.de/4671
Was es kann:
-Eingabefelder: die Länge kann begrenzt und ein Standarttext definiert werden.
- unterarten von Eingabefeldern: Zahlenfelder, Passwortfelder
- Checkboxen
- Radioboxen
- Labels (auch mehrzeilig)
- Meldungen auch mehrzeilig und in 3 Typen: Nachfragen, Wartemeldungen und einfach Masanges. Hier können Farbpaare übergeben werden.
- Buttons
Was es nicht kann:
-Ohne Probleme mit dem Fokus Widgets entfernen/hinzufuegen
-Ohne fokus auskommen (d.h. wenn nur Labels vorhanden sind gibt es eine Endlosschleife)
-Widgets sichtbar deaktivieren. So geht es nur durch schreiben des Atributes takefocus
-Widgets automatisch ausrichten
Ein Beispielprogramm liegt bei![/list][/list]
simples TUI-Toolkit
Statt:
...kannst du auch direkt über `"1234567890"` iterieren. Oder halt `"".join(str(n) for n in xrange(10))`. 
Was noch auffällt ist, dass Leerzeichen an manchen Stellen die Lesbarkeit ungemein erhöhen würden. Mit der Programm-Logik an sich hab ich mich jetzt nicht näher beschäftigt.
Code: Alles auswählen
if not chr(x) in ["1","2","3","4","5","6","7","8","9","0"]:Was noch auffällt ist, dass Leerzeichen an manchen Stellen die Lesbarkeit ungemein erhöhen würden. Mit der Programm-Logik an sich hab ich mich jetzt nicht näher beschäftigt.
-
BlackJack
@snafu: ``if not chr(x).isdigit():`` ginge auch noch.
@Armageddon: Du nutzt Tab zum Einrücken bzw. manchmal auch Leerzeichen. Der Quelltext ist so zum Beispiel bei mir im Editor "unlesbar" weil ein Tab bei mir standardmässig als vier Leerzeichen dargestellt wird, Du allerdings anscheinend von acht ausgehst. Alle Methoden-``def``\s werden bei mir deshalb auf der gleichen Ebene angezeigt wie deren Körper.
Das `screen`-Attribut kommt bei den Klassen einfach aus dem "nichts". Das sollte man wenigstens in der `__init__()` an `None` binden.
Anstelle der vielen "magischen" Zahlen sollte man besser Konstanten verwenden. Also zu Beispiel `curses.ascii.DEL` statt 127.
Sprachen mischen ist nicht so toll. `takefocus` und `fokus` in ein und der selben Klasse ist verwirrend und verleitet dazu eines von beiden irgendwann mal falsch zu schreiben.
`IntEntry` teilt sich einen Grossteil der `push()`-Methode vom `TextEntry`. An der Stelle würde ich über eine `validate()`-Methode nachdenken, die den neuen Inhalt des Widgets gegen irgendeine Bedingung prüft. Beim `TextEntry` kann die immer `True` liefern und bei Unterklassen kann man sie dann überschreiben und zum Beispiel testen ob die Zeichenkette ein gültiges `int` wäre. Vielleicht sogar optional mit Ober und/oder Untergrenze.
Ebenfalls viel gemeinsam haben `RadioBox` und `CheckBox`.
Bei `Label.render()` fallen mir die kurzen Namen sehr unangenehm auf. Ist es wirklich so schlimm `lines` statt `l` zu schreiben? Das `l` kann man zudem bei einigen Schriftarten sehr leicht mit einer 1 verwechseln. Aber letztendlich hätte ich das gar nicht an einen Namen gebunden. Das manuelle hochzählen von `i` lässt sich mit `enumerate()` vermeiden.
`Dialog.Widgets` verstösst gegen die Namenskonvention in PEP8. Warum gerade hier diese Ausnahme?
Das `type_`-Argument bei `alert()` widerspricht OOP. Die Methode tut zuviele verschiedene Dinge. Ein ``else`` am Ende sollte prüfen, ob der Aufrufer einen unbekannten `type_` übergeben hat.
In der `mainloop()` ist zweimal der gleiche Quelltext um den Fokus weiterzusetzen. Und der hat Probleme. Einmal wenn es keine Widgets gibt, und dann wenn es keine gibt, die den Fokus entgegennehmen. Dann ist das nämlich eine Endlosschleife.
Wenn man Wahrheitswerte meint, sollte man keine Zahlen verwenden. ``while 1:`` schreibt man also besser als ``while True:``.
`x` und `y` für Koordinaten ist ja in Ordnung, aber in einem Programm das diese Namen für Koordinaten verwendet, sie auch noch für Tastaturcodes zu verwenden ist sehr verwirrend.
@Armageddon: Du nutzt Tab zum Einrücken bzw. manchmal auch Leerzeichen. Der Quelltext ist so zum Beispiel bei mir im Editor "unlesbar" weil ein Tab bei mir standardmässig als vier Leerzeichen dargestellt wird, Du allerdings anscheinend von acht ausgehst. Alle Methoden-``def``\s werden bei mir deshalb auf der gleichen Ebene angezeigt wie deren Körper.
Das `screen`-Attribut kommt bei den Klassen einfach aus dem "nichts". Das sollte man wenigstens in der `__init__()` an `None` binden.
Anstelle der vielen "magischen" Zahlen sollte man besser Konstanten verwenden. Also zu Beispiel `curses.ascii.DEL` statt 127.
Sprachen mischen ist nicht so toll. `takefocus` und `fokus` in ein und der selben Klasse ist verwirrend und verleitet dazu eines von beiden irgendwann mal falsch zu schreiben.
`IntEntry` teilt sich einen Grossteil der `push()`-Methode vom `TextEntry`. An der Stelle würde ich über eine `validate()`-Methode nachdenken, die den neuen Inhalt des Widgets gegen irgendeine Bedingung prüft. Beim `TextEntry` kann die immer `True` liefern und bei Unterklassen kann man sie dann überschreiben und zum Beispiel testen ob die Zeichenkette ein gültiges `int` wäre. Vielleicht sogar optional mit Ober und/oder Untergrenze.
Ebenfalls viel gemeinsam haben `RadioBox` und `CheckBox`.
Bei `Label.render()` fallen mir die kurzen Namen sehr unangenehm auf. Ist es wirklich so schlimm `lines` statt `l` zu schreiben? Das `l` kann man zudem bei einigen Schriftarten sehr leicht mit einer 1 verwechseln. Aber letztendlich hätte ich das gar nicht an einen Namen gebunden. Das manuelle hochzählen von `i` lässt sich mit `enumerate()` vermeiden.
`Dialog.Widgets` verstösst gegen die Namenskonvention in PEP8. Warum gerade hier diese Ausnahme?
Das `type_`-Argument bei `alert()` widerspricht OOP. Die Methode tut zuviele verschiedene Dinge. Ein ``else`` am Ende sollte prüfen, ob der Aufrufer einen unbekannten `type_` übergeben hat.
In der `mainloop()` ist zweimal der gleiche Quelltext um den Fokus weiterzusetzen. Und der hat Probleme. Einmal wenn es keine Widgets gibt, und dann wenn es keine gibt, die den Fokus entgegennehmen. Dann ist das nämlich eine Endlosschleife.
Wenn man Wahrheitswerte meint, sollte man keine Zahlen verwenden. ``while 1:`` schreibt man also besser als ``while True:``.
`x` und `y` für Koordinaten ist ja in Ordnung, aber in einem Programm das diese Namen für Koordinaten verwendet, sie auch noch für Tastaturcodes zu verwenden ist sehr verwirrend.
Wobei man da zugegeben auch auf den konkreten Anwendungsfall gucken muss:BlackJack hat geschrieben:@snafu: ``if not chr(x).isdigit():`` ginge auch noch.
Code: Alles auswählen
>>> str(12) in "123"
True
>>> str(12) in map(str, [1,2,3])
False
>>> "12".isdigit()
True
-
Rebecca
- User
- Beiträge: 1662
- Registriert: Freitag 3. Februar 2006, 12:28
- Wohnort: DN, Heimat: HB
- Kontaktdaten:
Es gibt ja auch noch string.digits...
Offizielles Python-Tutorial (Deutsche Version)
Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
-
jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Hab mal die Einrückung korrigiert: http://pastebin.de/4684