Ist das nicht eine Abhängigkeit des Sprachsatzes der bei "Schriftart"(glaube ich hieß das) gewählt wird ?jerch hat geschrieben: 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.
Terminalausgabe bunt machen
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 ?
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 ?
@Xynon1: Die Zeichenkodierung hat nichts mit Farben zu tun, sondern sagt nur welche Zahl(en) zu welchem Zeichen abgebildet werden.
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.
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.
-
- User
- Beiträge: 48
- Registriert: Donnerstag 17. September 2009, 16:44
- Kontaktdaten:
vllt. könnte man auch was in richtung acoc angehen