Willkommen zur Froscon Cloud Edition 2021, heute hier wieder im Development Track. Es geht jetzt mit Martin Hoestetter, Hoestettler, Verzeihung, ist doch ein Zungenbrecher, um TermPaint, eine moderne Low-Level-Terminal-Abtraktionsschicht.

Und, ja, ich bin gespannt. Wir werden hoffentlich ganz viel lernen über Terminals, wie man da eigentlich Buchstaben und Zeichen und so drauf bekommt. Und, bitteschön. Ja, hallo, danke für die Ankündigung. Ja, es geht heute um TermPaint, eine Low-Level-Terminal-Access-Library.

Aber, wie so häufig, wir machen erst mal eine Zeitreise in die 90er. Vielleicht erinnert sich jemand von euch an die DOS-Textmod-Anwendungen, die damals verbreitet waren. Ein deutlicher Kontrast zu dem, was man heute meistens als Terminal-Anwendungen hat,

weil das einfach ein anderer Kontext war, daraus haben sich unsere modernen GUI-Anwendungen entwickelt. Wäre es nicht auch schön, sowas im Terminal heutzutage zu haben? Das wäre zum Beispiel eine mögliche Anwendung von TermPaint. So, Terminals in 2021.

Ja, immer noch. Commandline ist immer noch produktiver, als in irgendwelchen GUIs rumzuklicken. Und wenn man in der Commandline ist, dann ist es sinnvoll, andere Dinge auch direkt im Terminal zu machen, um nicht Kontext-Switchen zu müssen. Ja, Terminals weigern sich zu sterben, das mit Recht. Und wir haben natürlich immer noch die Use Cases mit SSH,

um remote auf Servern irgendwas zu machen, wo auch die Terminal-Anwendung eigentlich immer noch ohne Konkurrenz, ohne ernsthafte Konkurrenz ist. Und wer es will, kann es auch im Browser benutzen. Ja, wie funktionieren Terminals? Also, was ist das grundsätzliche Modell? In erster Näherung hat man erstmal Eingabe von Buchstaben

und Ausgabe in einem festen Raster von Zeichen. Und dann haben sich mit der Zeit diverse zusätzliche Dinge ergeben. Vordergrundfarben, Hintergrundfarben, Fettdruck, beziehungsweise früher hellere Intensität unter Streichungen. Diverses. Ja, also eigentlich ganz einfach.

Oder halt auch nicht. Tastatureingaben sind plötzlich auch Tastenkombinationen. Was passiert, wenn ich Steuerung Shift A drücke? Wir haben in der Tastatur Tasten, die keinem Zeichen entsprechen. Und die Tastatureingabe ist aus historischen Gründen nicht präfixfrei. Das heißt, wenn man das ESC-Zeichen von einem Terminal bekommt,

weiß man nicht, ob es ein Teil von einer längeren Sequenz ist oder ob der Kunde tatsächlich ESC gedrückt hat. Ja, Maus hat sich ergeben. Klar, will man irgendwie nicht darauf verzichten. Die einen wollen damit kopieren, die anderen wollen damit tatsächlich die Anwendung bedienen. Dann gibt es Unicode.

Unicode ist in vielen Bereichen natürlich immer mehr Komplikation. Im Wesentlichen, weil Sprachen schwieriger sind, als wir gerne hätten. Aber im Terminalbereich hat man da vor allen Dingen, dass sich Breitezeichen ergeben. Dann wird das Modell plötzlich ein wenig aufgelöst. Das Gitter ist plötzlich kein eindeutiges Gitter mehr,

sondern es gibt Zeichen, die breiter sind, es gibt Zeichen, die normalbereit sind. Das wird noch schöner, wenn man sich Unicode-Flaggen anschaut. Die Terminals unterscheiden sich da, ob sie dafür vier Zellen benutzen oder vielleicht auch nur zwei. Ja, und wenn man noch mehr Komplikation will,

dann gibt es sowas wie Grafikprotokolle. Und zwar nicht nur eins, sondern jedes Terminal hat ein eigenes. Ja, und zwischen dem Terminal und den Anwendungen steht da noch so ein Körner. Das ist auch, wo sich auch Dinge historisch entwickelt haben. Es gibt einen Canonical-Mode,

in dem der Körner eigentlich einen minimalen Zeilen-Editor hat. Den kann man zum Beispiel sehen, wenn man einfach nur Cat eingibt. Und dann kann man trotzdem Text editieren. Der ist sehr minimal. Im Wesentlichen funktioniert Backspace. Aber auch sowas wie Steuerung D drücken, um Ende der Eingabe zu signalisieren,

ist ein Teil von diesem Terminal, von diesem Kernel-Mode-Kram. Für anspruchsvollere Anwendungen will man das natürlich ausschalten und in Raw-Mode wechseln. Was zum Beispiel auch Bech macht. Die benutzen dafür allerdings eine Library-Readline, die das dann managt.

Ja, ansonsten macht der Kernel andere interessante Dinge. Es gibt unter Unix hat man ja, dass Zeilen n nur Carriage-Return sind. Das ist also Backslash-n. Aber Terminals benutzen in Wirklichkeit C-A-L-Fs für Zeilen-Umbruch und dann wieder zurückgehen auf den Anfang der Zeile.

Das ist also eine Sache, die defaultmäßig im Kernel als Konfiguration hinterlegt ist, dass das transformiert wird. Dann hat der Kernel eine weitere Funktionalität, dass man zum Beispiel, wenn man Steuerung C drückt, eine Anwendung abbricht. Das heißt, das ist auch in dem Kernel-Teil implementiert

und die Anwendung, wenn sie Control C tatsächlich benutzen möchte, müsste das ausschalten. Davon gibt es noch mehr. Steuerung Z, Steuerung Backslash für Quid. Der Kernel sendet anderen Kram. Buffering. Terminalgröße ist etwas, was natürlich für die Anwendungen sehr spannend ist,

weil wenn der Benutzer in seinem Terminal die Größe ändert, dann will man das natürlich sehen. Also, wir haben hier in dem Beispiel mal so ein Xterm, der kommuniziert mit dem Kernel über das Pseudoterminal-Controlinterface und auf der anderen Seite gibt es ein Pseudoterminal,

wo dann mehrere Anwendungen dranhängen. Typischerweise hat man als erstes seine Shells, zum Beispiel hier in dem Beispiel Bech, aber es können natürlich auch andere Shells sein und dann hat man alles, was man in der Bech startet, erst mal auch zusätzlich hier dran. Zum Beispiel hier in dem Beispiel haben wir einen Hardtop,

der dann intern als Terminal-Abstraktions- und Zugriffs-Library Endkurses verwendet. Aber gibt es natürlich auch in Komplexer, zum Beispiel wenn man SSH macht, dann hat man da plötzlich mehrere Körner im Bild und der SSH muss mit einem SSHD sprechen und letztendlich sieht die Situation auf der Anwendungsseite

aber wieder ähnlich aus, weil der Körner auf der Seite von dem SSH wird halt auf transparent geschaltet, sodass er keine Transformation mehr macht, weil sonst hätte man die ja doppelt. So, das war jetzt erst mal ganz grob was über Terminals. Warum aber Turnpaint?

Ja, es gibt bestehende Libraries, aber die haben mir nicht unbedingt immer gefallen, teilweise aus historischen Gründen, weil sie halt einfach, Libraries aus den 80ern sind vielleicht nicht immer das Schönste, aber halt auch weil man gerne etwas haben wollte,

was den Fokus auf moderne Terminals hat, wobei in dem Fall modern so grob was UTF-8 kann ist, weil damit Dinge halt einfach wesentlich einfacher werden, dass man tatsächlich mehr als 128 Zeichen oder so ähnlich haben kann. Integration in Event Loops

ist in der klassischen Terminal Library Welt jetzt nicht so die Priorität gewesen. Andererseits, ich denke mal heutzutage werden die meisten Leute, die UI-Programmierung haben, entweder explizit mit Event Loops arbeiten oder wie in JavaScript davon ist es gewohnt sein,

dass die Event Loop halt einfach unsichtbar, aber trotzdem vorhanden ist. Tempaint erlaubt aber auch, dass man synchron verwenden kann, um einfache Anwendungen zu schreiben, die halt die Komplexität einer eigenen Event Loop-Integration nicht benötigen. Eine andere Sache, die für mich immer sehr wichtig war,

ist ein robustes Keyboard-Handling zu haben, weil es ist einfach nicht zeitgemäß, dass wenn man eine Tastenkombination drückt, die irgendwo nicht richtig hinterlegt ist, dass man dann im Terminal irgendwelche Zeichen bekommt, die ja da nicht hingehören oder in der Anwendung plötzlich irgendwelche Funktionen ausgelöst hat,

wo man auch dann nicht mehr weiß, was es eigentlich genau ist, weil wer weiß schon, was Steuerung File Links genau intern für ASCII-Buchstaben enthält. Eher uninteressant. Und die andere Sache ist, eine Abstraktionsschicht sollte sich auf das konzentrieren,

was sie wirklich tun soll. In dem Fall, wenn man Low-Level-Terminal-Handling haben will, dann will man sich mit der Breite von Text beschäftigen, dann will man Textausgabe machen, dann will man natürlich Eingabe von Events haben, aber man sollte die Anwendung, die das verwenden will,

nicht direkt darauf festlegen, wie die UI-Konzepte aussehen müssen, weil, ja, es gibt viel Auswahl und einige wollen lieber was haben, was sich wie Vim bedient, andere wollen vielleicht lieber etwas, was sich wie edit.com bedient. Da gibt es viele Unterschiede und das sollte eigentlich die Rolle von einer Library sein,

die irgendwie höher im Stack angesiedelt ist. Ja, okay, was haben wir denn für Prinzipien? Ich habe mal überlegt, eigentlich will man, dass die Core-Library unabhängig davon ist, wo die Daten herkommen, wie ist das Terminal angebunden? Das heißt, nur IO, der Benutzer, kann definieren, wie die Kommunikation mit dem Terminal wirklich funktioniert.

Das kann ein System-Terminal sein, das kann ein Websocket sein und ich wollte Features konkret abbilden. Ein Cursor ist in vielen Terminals in verschiedenen Formen zu haben. Man kann ihn als Unterstreichung haben, als vertikalen Strich oder als Block.

Da bringt es niemanden weiter, eine Abstraktion zu haben, die sagt, hier gibt es einen Very-Visible-Mode. Was ist denn das? Was heißt das in meinem Terminal? Das heißt, es ist besser, Dinge wie den Alternate-Screen oder sowas tatsächlich mit dem als das abzubilden,

was tatsächlich auch passiert und nicht, wie man es historisch mal irgendwann eingebunden hat, wie die Feature neu und unüblich war. Ja, und Portable ist C. Klar, Portabilität ist immer gut, wenn eine Library eingesetzt werden soll.

Dann, was ich eben schon angesprochen habe, eine Low-Level-Terminal-Library sollte sich wenig mit dem, was auf der Anwendungsseite passiert, beschäftigen. Also keine Fenster, keine Panels, keine fertigen Input-Elemente, weil das alles Dinge sind,

wo man viele verschiedene Meinungen darüber haben kann und die auch alle irgendwie richtig sind und in irgendeinem Kontext auch die richtige Lösung sind. Andererseits braucht man Dinge wie Clipping, damit eine High-Level-Library sagen kann, okay, ich will Text in diesem Bereich zeichnen, mach den Text an diese Stelle und wenn er zu groß ist,

soll er abgeschnitten werden an der richtigen Stelle, weil ansonsten wird die Library die ganze Zeit sich nur damit beschäftigen, jeden Buchstaben einzeln zu vermessen und zu überlegen, passt das jetzt noch oder nicht. Eine andere nützliche Funktionalität ist, dass eine Library sowas Ähnliches wie Bitmaps im Speicher bzw. halt in dem Fall Upscreen-Surfaces haben kann,

sodass man Dinge schon mal vorbereiten kann, dass man das eine Software-Komponente etwas, eine andere Software-Komponente fertig gerendert übergeben kann. Ja, auf der anderen Seite wollte ich die Library so haben,

dass sie auf dem Terminal-Interface sich konzentriert, dass da verschiedene Terminals sinnvoll funktionieren, aber auch, dass man sinnvolle Defaults hat und dass man Optionen hat, wenn sich Dinge anders verhalten sollen, weil auch da in dem Bereich gibt es natürlich immer die Sache, dass verschiedene Anforderungen existieren, will man Maus haben, will man keine Maus haben,

ich denke, da haben wir gesehen, wie Debian den Maus-Modus Default aktiviert hat, wie die Herzfrequenz bei einigen hochgegangen ist. Ja, also auch da, man braucht Optionen, aber auf der anderen Seite ist es da auch sinnvoll, dass eine Terminal-Library tatsächlich eine Position bezieht,

währenddessen im UI-Bereich das eher weniger ist. Ja, gut, ich hatte nichts gefunden, was sich so richtig schön ergeben hat, um Terminal-Anwendungen damit zu schreiben. Also, Terminal schreiben. Erstmal schauen, wo gibt es eine Dokumentation? Ja, Internet ist voll mit irgendwelchen Sachen,

die die einfachsten Dinge beschreiben, aber wenn man tatsächlich wissen will, wie es wirklich funktioniert, dann sucht man ja nach Dokumentation von den Terminals selber. Dann gibt es ein Terminal-X-Term, was die beste Dokumentation eigentlich hat von den aktuell maintainten Terminals.

Aber auch da, der typische Detailgrad ist, eine Beschreibung des Syntaxes und ja, ein oder zwei Sätze, sowas wie löcht n Zeichen aus der Zeile. Andere Terminals haben oft keine oder halt auch ein Zeiler als Dokumentation. Ja, gibt es irgendwas Offizielles?

Es gibt von DEC, von denen diese ikonischen VT-100-irgendwas-Terminals bzw. VT-500-irgendwas später Terminals gemacht wurden. Gibt es interne Dokumentationen, wie sich Terminals allgemein verhalten sollten? Ja, ist jetzt nicht mehr so intern,

liegt mittlerweile überall im Internet herum. Beschreibt aber natürlich irgendwie überhaupt nicht die heutige Welt. Auf der anderen Seite gibt es tatsächlich Standards von ECMA beziehungsweise je nachdem, diese Standards sind auch unter ISO und ANSI veröffentlicht worden.

Das ist, was uns die ANSI Terminals oder ANSI Escape Sequenzen als Wording beschert hat. ECMA 48 ist auch alt, aber vor allen Dingen so ein typischer Standard aus dem Komitee. Es gibt 100.000 Optionen, davon sind irgendwie 10% implementiert.

Das war auch für Dokumentenverarbeitungssysteme und Drucker gedacht. Ja, keine gute Übereinstimmung mit der Realität an der Stelle. Also alles keine solide Basis, um wirklich eine Terminal-Library zu entwickeln. Also, wie geht es weiter? Okay, offensichtliche Lösung.

Die Terminals, die interessant sind, sind Open Source, also kann man in Source Code lesen. Ja, stellt sich raus, ist alles nicht so einfach. Ich habe Notizen erstellt, aber das ist irgendwie schnell unübersichtlich geworden. Und dann habe ich gesagt, ja, sollte man vielleicht tatsächlich erstmal sauber dokumentieren, damit ich überhaupt entscheiden kann, was geht eigentlich, was kann ich machen, was geht nicht,

wie kann ich möglicherweise Quirks von Terminals erkennen oder sonst irgendwas. Ja, und wenn man es schreibt, dann stellt man es am besten auch ins Internet, damit irgendjemand anderes von profitieren kann. Ja, und das ist tatsächlich eine Dokumentation, die tatsächlich die verschiedenen Terminals betrachtet.

Das heißt, man sieht halt auch, was denn zum Beispiel vielleicht eine Konsole anders macht, als ein Genom-Terminal oder ein X-Term. Typischer Detailgrad an der Stelle, eher Pseudocode als gute Sprache, aber ja, bildet halt eher das, was die Terminals machen und so oft ist es halt kompliziert,

insbesondere wenn Features miteinander interagieren, weil ja, auch die Terminals haben mittlerweile mit der Zeit viele Features entwickelt, die dann irgendwelche Modes aktivieren oder nicht und verschieden sind.

Ja, weiter zu der Terminal-Kommunikation. Die Applikation zur Terminal-Kommunikation ist tatsächlich in den frühen Standards, also ECMA 48, mit einem sinnvollen Syntax versehen worden. Terminals davor haben sicherlich andere Dinge gemacht, irgendwie so VT50 oder so,

die spielen aber zum Glück keine Rolle mehr, so dass wir jetzt eine Situation haben, wo man eine klare Erwartung hat, wenn man korrekt syntaktisch formulierte Nachricht schickt an das Terminal und das Terminal, die nicht versteht, dann soll es die halt ignorieren. Wenn man Pech hat, gibt es irgendwas auf die eigene Debug-Konsole aus,

aber im Wesentlichen funktioniert das. Die andere Richtung ist komplett historisch gewachsen und ja, ein wenig problematisch an der Stelle, weil es ist, wie gesagt, nicht präfixfrei. Es werden ECMA 48 Escape-Sequenzen zwar geschickt, aber da Escape auch eine Taste ist, kann man die nicht so richtig voneinander unterscheiden.

Die übliche Lösung, die die meisten Libraries an der Stelle gehen, sind reine Timeouts, das heißt, wenn nach einem Esk-Zeichen irgendwie so und so viele Millisekunden nichts Weiteres mehr kommt, dann ist es ja offensichtlich ein Esk gewesen, weil Netzwerk-Delays oder sowas kommen ja nicht vor.

TermPaint geht an der Stelle einen etwas anderen Weg. Bei Unklarheiten wird das Terminal gezwungen, mehr Daten zu senden, um dann anhand der weiteren Daten die Sachen auseinanderhalten zu können. Das heißt, wenn man Escape drückt und dann eine Zeit lang nichts mehr kommt, dann sendet TermPaint eine Status-Anfrage an das Terminal

und das Terminal antwortet mir, mit mir geht es gut. Und damit ist aber die Sequenz dann plötzlich lesbar und eindeutig. Ja, verschiedene Terminals. Früher gab es eine große Vielfalt von Terminals und auch sehr verschiedene Programmiermodellen.

Das heißt, die klassische Lösung ist so eine Terminalvariable, die auch sehr gut funktioniert hat, wie man Systeme mit Systemadministratoren hatte und die Terminals verschieden genug waren, als dass man tatsächlich darauf angewiesen waren, dass verschiedene Terminals auch richtig konfiguriert waren. Wie sich die Konsolidierung meistens ergibt,

wir haben mittlerweile eigentlich nur noch ein Modell, was im Linux-Bereich relevant ist, was mich eigentlich im Prinzip als so ähnlich wie extern bezeichnen lässt. Ja, und da die Terminal-Info-Datenbanken ohne Systemadministratoren oder mit Systemadministratoren die, ja, packt das System nicht an,

da ist ein Cent aus sechs drauf. Da wollen wir nichts mehr daran ändern. Fahren ist die Datenbank halt nicht aktuell, wenn sich irgendwelche Dinge in Terminals ändern. Und fast alle Terminals haben sich entschieden, dass die richtige Variante damit umzugehen ist, zu sagen, ich mache zwar nur 20 Prozent von Terminal-Sequenzen,

es gäbe Sequenzen, aber ich behaupte mal, ich wäre ein extern. Damit funktioniert das eigentlich am besten. Ja, funktioniert also heute mit dem Dollar-Term nicht mehr so gut. Das heißt, ThermPaint hat an der Stelle die Entscheidung hartgecodet, dass Dollar-Term einfach ignoriert wird

und stattdessen wird das Terminal gefingerprintet. Das heißt, es werden Sequenzen hingesendet. Einige Terminals haben tatsächlich Sequenzen, auf die sie sich melden mit, ja, ich bin im übrigen Terminal aus dem Projekt so und so. Einige Terminals erkennt man am besten daran, dass sie Bugs haben.

Ja, besser wäre es natürlich, einen modernen Standard zu haben, wo man das Terminal fragen kann, was kannst du eigentlich? Ja, da sind Dinge in Arbeit, aber es sind viele Projekte und viele Meinungen, dementsprechend bewegt sich da langsam, Dinge langsam und es gibt halt offene Fragen,

ob man eine Baseline definieren will oder nicht. Ja, Symbolbild, Terminalerkennung, State Machine mit 30 States, ja, kann man machen, ist nicht schön, aber es scheint mir im Moment das Beste zu sein, um zu erkennen, was für einen Terminal man tatsächlich auf der anderen Seite hat.

Ja, zurück zu dem Modell, wie ThermPaint die Abstraktion macht, relativ unüberraschend, es ist auch ein 2D-Arry von Zellen, wobei wir halt als Zellen, Zellen sind halt, haben eine feste Breite, aber im 2 für 2 gibt es ein Cluster, das zwei Zellen zusammen verbindet

für doppelt breite Zeichen, zum Beispiel, wenn man Japanisch oder Emoji oder sonst irgendwas braucht. Je Zelle oder Cluster wird ein entsprechender Text gespeichert, hier ist natürlich Unicode wieder zu beachten,

es ist nicht ein Zeichen, ein Code-Point, sondern im Zweifelsfall können halt, man kann ein A auch als A mit Punkte drunter haben und dann sind das im Unicode zwei Zeichen, aber es gibt zusammen halt ein Cluster. Ja, Farben braucht man natürlich, müssen wir abbilden können,

Vordergrund, Hintergrund, einige Terminals erlauben, Dekorationsfarben, das ist meistens die Unterstreichung, die man unterschiedlich hat, damit man auch rot unterkringelt als Markierung für die Rechtschreibkorrektur verwenden kann, Attribute haben Terminals, Bold, Underline, Diverses, Anderes

durchgestrichen und es ist immer so, dass Terminals sich weiterentwickeln, dementsprechend gibt es für Spezialisten zusätzlich noch die Möglichkeit, Raw Escape Sequenzen anzugeben, so was man sagen kann, okay, ThermPaint unterstützt zum Beispiel im Moment keine URL Escape Sequenzen,

die dann dafür sorgen, dass der Browser, das ist das Terminal, die eine richtige URL anzeigt, auch wenn zum Beispiel die URL nur teilweise auf dem Bildschirm zu sehen ist, das kann man dann auf die Weise zusätzlich einbinden, sodass man nicht gezwungen ist, zu warten, bis ThermPaint jede Feature unterstützt, die man benutzen möchte.

Ja, eine weitere Sache ist, wenn wir Cluster haben, die zwei Zeichen breit sind, was passiert eigentlich, wenn die zur Hälfte überschrieben werden? Ich habe da mit einem Terminal-Emulator bei meinem Dokumentieren festgestellt, dass es komplett inkonsistent war, was da passiert,

inklusive interne Datenstrukturen waren komisch, dementsprechend ist an der Stelle eine Entscheidung gefallen, dass wenn ein Cluster zerfällt oder wenn irgendwas überschrieben wird, dass er erst in Leerzeichen umgewandelt wird, sodass zum Beispiel Hintergrundfarben konsistent bleiben.

Ja, ansonsten gibt es zu jedem Terminal eine primäre Oberfläche, ThermPaint unterstützt im Prinzip in einem Prozess auch mehrere Terminals einzusteuern, es wäre dann relevant, wenn man zum Beispiel WebSockets hat oder sowas, gibt es eine primäre Oberfläche, die kann man Dinge draufmalen

und dann kann man synchronisiert auf das Terminal ausgeben, wenn es fertig ist mit Flasche und genau, es gibt die Offscreen Surfaces, damit einzelne Komponenten innerhalb der Software Daten rumreichen können, die fertig erzeugt sind.

Eingabemodell ist auch moderne Bedürfnisse getrimmt, es gibt Callbacks, die aufgerufen werden, es gibt eine entsprechende Datenstruktur, in der sich Events auch hinzufügen lassen, ohne dass man Klimmzüge machen muss, wie dieses eine besondere Zeichen heißt, das ist ein Mausevent,

jetzt musst du noch mal irgendwo anders nachfragen. Ja, im Wesentlichen, die Kernevents sind aber natürlich die üblichen, man kann Zeichen eingegeben haben, potenziell mit Modifern, Steuerung A oder Steuerung Z, aber es gibt halt auch zusätzlichen Event für andere Tasten, sowas wie Kontroll F7.

Ja, wenn es aktiviert ist, sind Mausevents natürlich wichtig, mit den üblichen zu erwartenden Daten, XY, welcher Button wurde gedrückt, Terminals senden freundlicherweise den Modifier, sodass man auch sowas wie Steuerungklick implementieren könnte, wobei das mit den Modifern je nach Terminal eingeschränkt ist, welche Klicks denn gesendet werden.

Einige Terminals reservieren einfach gewisse Dinge für sich selber. Und dann gibt es noch einen ganzen Satz an zusätzlichen Events, die man bekommen kann, wenn man sie anfordert, sowas wie, es wurde was aus einem Clipboard im Terminal eingefügt, was ja in vielen Fällen anders behandelt werden sollte,

als wenn jemand tatsächlich was getippt hat. Fokus kann man bekommen von einigen Terminals. Es gibt noch interessant einen Repaint-Request. TermPaint hat an einigen Stellen Einstellungen, wie zum Beispiel Cursor-Farben, die TermPaint wieder zurücksetzen möchte, wenn die Anwendung sich beendet.

Und an der Stelle muss dann erst mit dem Terminal kommuniziert werden, wenn der Benutzer diese Feature haben will, um herauszufinden, ja, geht das überhaupt? Kann ich das restoren? Und wenn ich es nicht restoren kann, dann vielleicht will ich es auch nicht direkt ans Terminal senden. Und wenn sich an der Stelle die Kenntnis von dem, was geht, geändert hat,

dann gibt es dann ein Repaint-Request, sodass die Anwendung dann sagen kann, okay, darauf kann ich jetzt reagieren. Ja, Anwendungen haben natürlich irgendwie immer so eine gewisse Form, ein gewisses Gerüst. Die Anwendung leitet Beides vom Terminal an TermPaint weiter und von TermPaint zum Terminal. An der Stelle ist es so, dass die Beides vom Terminal an TermPaint

eine Sache ist, wo die Anwendung sich halt aktiv drum kümmern muss, beziehungsweise eine Integration in irgendeine Message Loop. Aber die Richtung vom TermPaint zum Terminal, da gibt es halt auch wieder Callbacks, die TermPaint aufruft und sagt, okay, ich habe jetzt hier 15 Bytes, schick mal ans Terminal.

TermPaint kann auf die Weise auf Daten vom Terminal reagieren, zum Beispiel, wie gesagt, um die Eingabe eindeutiger zu machen oder beim Fingerprinting direkt um zu entscheiden. Okay, ich habe jetzt eine Antwort vom Terminal. Wo geht es weiter? Was muss ich als Terminal als nächstes fragen? Ja, die Anwendung bekommt Callbacks

und die Anwendung steuert auf der anderen Seite mit der Sync-Funktion, wann der Bildschirm geupdatet werden soll, damit man an der Stelle halt auch Updates nur dann sendet, wenn notwendig, aber auch erst, wenn vollständig die Anwendung das darauf geschrieben hat.

So, ich glaube, ich bin ein bisschen schnell, aber ich hoffe, es ist nicht so schlimm. Add-on für Betriebssystemintegration ist natürlich immer schön. Das gibt es mit einer weiteren Sublibrary TermPaint X, damit man sich, wenn man einfache Anwendung schreibt, nicht die, ja, eine Event Loop Integration selber schreiben muss.

Schön wäre sicherlich irgendwann auch Projekte zu haben, die mit für alle üblichen Event Loops fertige Integration haben. Aber das ist noch nicht passiert. Im Moment gibt es halt einfach nur die eingebaute einfache Variante, geeignet für Anwendungen, die im Wesentlichen Tastatureingabe

und Zeit relevant sind, also ein Timeout auf irgendwas oder Reflechen alle 30 Sekunden. Wer an einer Anwendung selber auf Sockets reagieren möchte, also auf Sockets, die halt lange offen bleiben sollen,

dann braucht man entweder eine eigene Integration oder man kann natürlich Threads benutzen und irgendwie die Sachen an den Thread kommunizieren. Die TermPaint X enthält auch so ein bisschen Hilfsfunktionen für die Dinge vereinfachen, indem die Falls angenommen werden,

indem man annimmt, okay, wenn man Fullscreen-Anwendungen hat, dann will man die grundsätzlich auch mit den besten Terminal-Features enabled haben oder sowas. Es gibt ein paar Sachen, die sind halt so relevant, dass man auf jeden Fall die als Optionen angeben kann. Zum Beispiel, wenn man möchte, dass Steuerung C weiter vom Kölndl

behandelt wird, damit man entsprechend eine Anwendung einfach mit Steuerung C beenden kann, statt Steuerung C als Tastenkombination gesendet zu bekommen. Ja, es ist eine Low-Level-Library, also wie sieht ein Code aus? Grundsätzlich ist es eine Library, die den Ansatz geht

von objektorientierten C-Libraries. Das heißt, im Wesentlichen hat man Pointer, die man bekommt, die die Library alloziert, die man dann benutzt und am Schluss wieder freigibt, wo man aber selber in den Pointeren nur mit Funktionen darauf zugreifen kann.

Nichts Neues, ich denke, das machen die meisten aktuellen C-Libraries, die Abi-Kompatibilität behalten wollen, so oder ähnlich. Ja, die Variablen-Deklarationen sind hier in der Slide nicht drin, weil sonst ein bisschen unübersichtlich, aber im Wesentlichen ist das die Initialisierung, wenn man einfach nur Hello World ausgeben will,

eine Initialisierung von TempEndX, wo man halt sagt, okay, ich will Fullscreen Setup haben und in dem Fall soll der Kölndl die Signale mal weiter behandeln. Man gibt einen Event-Callback an, um zu verarbeiten,

wenn TempEnd irgendwelche Keyboard-Events erkannt hat oder welche von diesen anderen Events. Der Event-Callback bekommt einen Data Pointer, damit man pro Event-Callback verschiedene Terminals behandeln kann. In dem Fall ist es ein einfacher Terminal, es ist ein einfaches Callback, was nur Quid erkennen kann und ja, man übergibt eine Variable,

die das Ergebnis reingespeichert werden soll. Dann muss man aus dem Terminal das primäre Surface rausholen, damit man was hat, wo man drauf tatsächlich zeichnen kann. Da kann man dann zum Beispiel erst mal für eine definierte Hintergrundfarbe sorgen. In dem Fall ist es hier so ein bisschen die Default-Farbe.

Das ist so ein Konzept, was Terminals haben, was halt einfach die Default-Einstellung ist. Farben in Terminals sind ein bisschen kompliziert, weil es gibt True Color, es gibt Farben, die Kunden oder die Benutzer von Terminals gerne immer umkonfigurieren. Es gibt noch so ein 256-Farben-Modus,

der so mehr Farben abbildet, die auch normalerweise nicht umkonfigurierbar sind und ein bisschen kompatibler ist. Ja, in dem Fall einfach die Default-Farben. Als nächstes Text schreiben. Koordinate, wohin, auch hier wieder Farben. Und dann kann man mit Terminal Flash

die Informationen tatsächlich zum Terminal schicken. In dem Fall heißt False als zweites Argument, dass die Library das incremental macht, wenn sie schon weiß, was auf dem Bildschirm sein sollte. Wenn irgendwelche anderen Anwendungen den Bildschirm überschrieben haben und der Kunde zum Beispiel Steuerung L drückt,

dann gibt es die Möglichkeit, da True anzugeben, dass man dann alles auf jeden Fall neu schreibt, um unabhängig davon zu sein, was in der Zwischenzeit auf dem Terminal passiert ist. Wir haben eben einen Event-Callback gehabt. Der ist hier eine ganz einfache Variante,

aber da sieht man, wie die Events grundsätzlich funktionieren. Jeder Event hat einen Typ. In dem Fall wird ein Typ von Char geprüft. Das heißt, das ist einfach eine Taste, die gedrückt worden ist, die in einem Buchstaben oder einem Sonderzeichen zugeordnet ist. Da wird einfach geprüft, ob in dem String

die Länge richtig ist und ob da ein Q drin ist. Das heißt, in dem Fall werden Modifier ignoriert. Das heißt, man kann mit Steuerung Q oder mit Alt Q oder mit ganz normal Q beenden. Ja, Escape ist natürlich auch was Schönes zum Beenden von Anwendungen oder auch nicht so üblich in Terminals,

aber das ist auch eine Möglichkeit. Hier sieht man halt, wenn man Key abfragt, diese Keys haben so einen Atom. Das kann man entweder als nullterminiertes String sehen oder man kann es vergleichen mit Pointern, die aus der Library zur Verfügung gestellt werden,

damit man an der Stelle nicht immer erst mal Strings bearbeiten muss. Und ja, was muss man machen, damit es überhaupt funktioniert, wenn die Anwendung auf Keyboard-Eingabe wartet oder sonst Informationen vom Terminal, kann diese Integration-to-Iteration-Methode aufrufen.

Die wartet einfach so lange, bis Keyboard-Eingabe da ist oder es gibt eine Variante bis Timeout, die dann entsprechend, wenn nichts eine gewisse Zeit passiert, auch der Anwendung wieder die Möglichkeit gibt, Dinge zu tun. Wer was Komplizierteres braucht, wie gesagt, auf irgendwelche Sockets reagieren oder sonst irgendwas,

da muss dann halt eine eigene Integration her. Oder später gibt es auch fertige Integration. Ich habe da so etwas mit Qt, was hoffentlich bald fertig wird. Ja, was ist der Stand an der Stelle?

Es läuft im Moment stabil auf den verbreiteten Terminals. Es gibt ein paar Edge-Cases, die bekannt sind, die nicht funktionieren. Sowas wie FreeBSD ohne graphische Benutzeroberfläche. Aber ich denke, da sind halt Dinge, die man noch optimieren kann bzw. mit FreeBSD ist so ein bisschen das Problem,

dass die sich gedacht haben, die Terminal-Status-Abfrage und überhaupt alles, was für Fingerprinting verwendet wird, brauchen sie nicht zu implementieren. Und außerdem, Terminal wird auch, also Dollar Term wird auch auf Xterm gesetzt. Ja, es gibt Leute, denen ist es nicht so einfach, mit diesem Konzept zu unterstützen.

Bisher ist es auch nicht unter Win32 getestet. Der Code benutzt eigentlich nichts Exotisches an C, aber ich bin noch nicht dazu gekommen, mich mit Windows rumzuschlagen. Für Leute, die WSL, also die Windows-Simulation für Linux quasi benutzen,

da funktioniert das mit passenden Terminals, die mit Escape-Sequenzen umgehen können. Das Standard alte Terminal von Windows ist nicht auf Escape-Sequenzen ausgerüstet, also kann das halt auch sowas wie Fingerprinting gar nicht überstehen. Ja, hoffentlich wird es irgendwann mal eine Wirklichkeit geben, an dem Fingerprinting vorbeizukommen,

aber das hat sich noch nicht verbreitet. Ja, Ausblick. Ja, die Low-Level-Library ist schön, damit kann man auch Anwendungen schreiben, aber es wäre natürlich schön, wenn für gewisse Use-Cases auch wir High-Level-Libraries haben. Am besten viele, bin ich nicht mehr zu hören.

Ansonsten, ja, so, okay, gut. Ja, es wäre schön, High-Level-Libraries zu haben, die dann verschiedene UI-Modelle abbilden können. Ideen für Anwendungen sind sicherlich,

ja, ich würde gerne mal einen Passwortmanager haben, der auch im Zweifelsfall per SSH zu erreichen ist. Ich habe auch mal überlegt, mit Git noch Dinge zu machen. Im Moment bin ich dran an der High-Level-Library für Widgets mit Qt, die halt so ein bisschen tatsächlich den Flair

von den DOS-Anwendungen ein bisschen abbildet, das heißt vielleicht auch den Flair von GUI-Anwendungen. Da bin ich dran, es ist immer Arbeit und hoffentlich bald ein Ergebnis. Was man unten sieht, ist zum Beispiel ein Programm,

was ein Editor ist. Ein Editor-Widget ist halt immer eine wichtige Sache für UI-Libraries, wenn man tatsächlich sowas wie Passwortmanager mit Notizen fällt oder ein Git, wo man halt auch Dateien bearbeiten will, haben möchte. Das ist an der Stelle ein Editor, der, ja, mit Menüleiste und anderen Dingen ist.

Wenn man den möchte, tipps den auch in blau. Damit bin ich soweit durch. Da sind die URLs für die Projekte von mir. Da könnt ihr gerne mal schauen und vielleicht auch das eine oder andere mitmachen. Meine E-Mail-Adresse natürlich.