Terminalausgabe bunt machen

[BlackJack]

@USER67: Ja das ist der Grund.

[USER67]

Kann ich es auch für 2.5 anwenden, ohne 2.6 zu installieren.

ich wende es auf der arbeit an und ich muss mit der aktuellen zurecht kommen.

vielleicht brauche ich dafür nur ein bestimmtes class aus 2.6 importieren?

Grus

[derdon]

Das kommt ganz darauf an, ob snafu (oder jemand anders) Lust dazu hat, Support für 2.5 zu implementieren. Wenn snafu aber str.format verwendet, denke ich, dass er ganz bewusst auf Support für 2.5 verzichtet hat.

[snafu]

Ich möchte mal anmerken, dass bisher nur Unix-Escape-Sequenzen implementiert sind. Ich glaube nicht, dass die auch für Windows gelten. Für Windows werde ich die Veränderungen vermutlich über die Windows API handlen. Letztlich plane ich die Abstraktion soweit, dass man nur noch Dinge wie `State('bold')` oder `TextColor('yellow')` auf Bibliotheksebene hat. Die begonnene Grammatik wird letztlich wohl so enden, wie in diesem Beispiel:

`"blink,#yellow,uline,&green,!bold"` -> blinkende, unterstrichene Schrift in gelb mit grünem Hintergrund und deaktiviertem Fett-Modus

Bei der Syntax bleiben die eckigen Klammern bestehen. Verschachtelungen sind möglich. Das soll auch für verschachtelte Farben gelten.

Über kurz oder lang soll über die API auch der aktuelle Status des Cursors oder die Fähigkeiten abgefragt werden können (`is_bold()`, `can_blink()` usw.) und das halt für die unterschiedlichen Terminaltypen wie `xterm`, `libvte-based`, `wincon` etc.

Wenn, ja wenn, es einmal fertig ist, sollen auf beliebigen Plattformen ohne viel Aufwand diverse Features zur Textformatierung genutzt werden können. Sei es für Syntaxhighlighter (Farben) oder für Hilfetexte (z.B. Hervorheben einzelner Wörter, Hilfen zur Einrückung, Aufzählungszeichen oder Rahmen um einen Textabschnitt). Also mir fällt da noch jede Menge ein. Es muss nur umgesetzt werden.

[jerch]

...Ich glaube nicht, dass die auch für Windows gelten. Für Windows werde ich die Veränderungen vermutlich über die Windows API handlen....

Früher zu DOS/Win3.X Zeiten gab es die Möglichkeit, einen Teil der ANSI-Codes auch am DOS-Terminal zu nutzen (ANSI.SYS), laut Wikipedia funktioniert das auch noch mit Vista und den x86-Versionen des Windows Server 2003. Allerdings muss der Nutzer hierfür die Konsole umkonfigurieren und neuere Windowsversionen scheiden offenbar gänzlich aus. Alles in allem - reichlich unpraktikabel.
Besser ist es, wie Du selbst geschrieben hast, auf die Konsolenfunktionen über die API-Calls zuzugreifen, da diese über die verschiedenen Windowsversionen hinweg quasi stabil sind und die Fähigkeiten der Winconsole abbilden. Bei Verwendung von ctypes und direktem Bibliothekszugriff musst Du vermutlich die Bittigkeit der Parameter beachten (habs bisher nur für 32-Bit Windows gemacht), mit der Win32-Erweiterung von Mark Hammond wirds wahrscheinlich noch einfacher.

In puncto Fähigkeiten gibt es ein paar Unterschiede zw. ANSI-Terminals und der Winconsole. So kann z.B. die Winconsole die aktuellen Texteigenschaften für Zelle xy zurückgeben, während die meisten ANSI-Terminals mehr Farben und Darstellungsmodi (z.B. durchgestrichen, unterstrichen) unterstützen. Für eine All-Bibliothek müsstest Du den kleinsten gemeinsamen Funktionalitäts-Nenner finden bzw. wiederum nach Plattformen getrennt die erweiterten Funktionen anbieten.

[Xynon1]

Früher zu DOS/Win3.X Zeiten gab es die Möglichkeit, einen Teil der ANSI-Codes auch am DOS-Terminal zu nutzen (ANSI.SYS), laut Wikipedia funktioniert das auch noch mit Vista und den x86-Versionen des Windows Server 2003.

Ist das nicht eine Abhängigkeit des Sprachsatzes der bei "Schriftart"(glaube ich hieß das) gewählt wird ?

[jerch]

Nein, das hat damit nichts zu tun.

ANSI.SYS ist eine Treiberdatei, die mittels config.sys bzw. separater Konfigurationsdatei (unter NT Derivaten) zusätzlich geladen werden muss.

[Xynon1]

Ok, das weiß ich auch noch, aber ich bezog mich eigentlich auf den Terminal unter den "neueren" Windows Version.
Also die Konsole, und diese sollte doch unabhängig von Sprachtreibern laufen, wenn man dort einen True Type Font benutzt kann.
Weil dort doch im Font die Zeichenkodierung definiert wird, oder liege ich hier dennoch daneben ?

[BlackJack]

@Xynon1: Die Zeichenkodierung hat nichts mit Farben zu tun, sondern sagt nur welche Zahl(en) zu welchem Zeichen abgebildet werden.

[Xynon1]

Ok, stimmt das hat damit wirklich nichts zutun.

[jerch]

Hier eine überarbeitete Version der farbigen Ausgabe für Windows --> http://paste.pocoo.org/show/290718/

Die API ist etwas benutzerfreundlicher geworden. U.a. gibt es einen Kontextmanager, der die Konsole vor dem Zurücklassen im Mickeymouse-Farbenkleid bewahren soll. Farben und Attribute sind jetzt direkt über Methoden setzbar. Änderungen der Vorder- und Hintergrundfarbe werden getrennt behandelt, die Schlusstags '{/fg}' und '{/bg}' bzw. die entsprechenden unset-Methoden restaurieren nun den vorherigen Farbwert und nicht den Standardwert (wie noch in der alten Version). Damit sind Farbschachtelungen möglich.

Edit: Code aufgeräumt und lambdas weitestgehend rausgeschmissen

Das Markup ist unverändert, hier würde ich snafus Lösung abwarten und evtl. entsprechend anpassen.

Mit dem jetzigen Stand sind die Darstellungsmöglichkeiten bzgl. Farbe und Schriftattributen unter Windows erschöpft. Man kann das natürlich noch weiter treiben und Boxen implementieren, dazu noch Eventhandler für Maus- und Keyboardaktionen, verschiedene Widgetklassen, Statusleiste etc. - und landet bei einer TUI. Allerdings dürfte die Nachfrage eher gering sein und der Aufwand kaum lohnen. Die DOS-Fenster-Zeiten unter Windows sind vorbei, auch sind die Möglichkeiten der Window-Konsole im Vergleich zu Unix-Konsolen sehr beschränkt. Wer es trotzdem braucht, kann immer noch auf bewährte TUIs wie TurboVision zurückgreifen, für Python wäre wohl eher 'urwid' mit besserem Windowssupport der richtige Ansatzpunkt.

[flying sheep]

vllt. könnte man auch was in richtung acoc angehen