Methode voor ANSI text formatting in xterm gezocht.

[blorf]

Hallo,

Ik weet niet zeker of dit de goede categorie is, devschuur/programming zou ook kunnen.

Een tijd geleden heb ik een menu-programmaatje gemaakt in C op FreeBSD. Deze werkt in xterm en gebruikt ANSI-sequences voor kleuren en cursor positioning. Om de vereisten zo laag mogelijk te houden en dit ook op minimaal compatible systemen moet gaan draaien wil ik liever geen lib als ncurses gebruiken, en wel de kale standaard xterm.

Een menu is niet meer dan een lijstje met keuze-opties omringd door een ASCII kadertje. Het kan bediend worden met up/down/escape/enter. Elke optie kan een submenu bevatten die gestart en actief wordt met <enter> , waarbij het hogere menu ook in beeld blijft staan maar niet-actief.
Wat ik wil is het niew gekozen actieve menu centreren in beeld, waarbij op het moment dat bijv. van hoofdmenu naar submenu wordt gegaan, daarheen wordt geschoven door het hele scherm te laten verspringen, liefst stapsgewijs, dus per regel/kolom zodat er enige 'animation' te zien is. Alleen is het in FreeBSD moeilijk om te achterhalen wat er in beeld staat. Wat wel lukt is de menu's bij openen dumpen naar een tijdelijk ANSI bestand. De scherm-content kan dus altijd hersteld worden, maar daarbij zijn we wel gebonden aan de huidige terminal settings. Een regel of kolom opschuiven kan niet zomaar.

Wat ik volgens mij nodig heb is een tool waarmee je ANSI-content in een groot virtueel tekstblok kan plaatsen en daaruit een selectie van een rechthoekig deel kan halen (x,y - hoogte, breedte) waarbij kleuren e.d. gewoon blijven bestaan en cursor posities vertaald worden naar naar waarden relatief aan die afzonderlijke rechthoek, dus linksboven is dan cursor positie (1,1)

Kent iemand iets dergelijks, of een betere methode?

[Hero of Time]

Waarom gebruik je ANSI ipv de standaard UTF8 wat door zo'n beetje elke terminal wordt gebruikt voor weergave? Als ik overigens opzoek wat nou ANSI is, kom ik uit op https://stackoverflow.com...i-ansi-format-differences, wat dit zegt erover:

ANSI: There's no one fixed ANSI encoding - there are lots of them. Usually when people say "ANSI" they mean "the default locale/codepage for my system" which is obtained via Encoding.Default, and is often Windows-1252 but can be other locales.

Dus, ANSI is niet echt een standaard te noemen. Neem daarom dus een characterset dat wél gestandaardiseerd is, zoals dus UTF8. Je zou dan in xterm geen probleem moeten hebben, omdat die (tegenwoordig) standaard al UTF8 doet.

[blorf]

Ik gebruik escape codes voor niets anders dan kleuren en cursor positioneren, zoals een
printf ("\033[%i;%if", y, x); de cursor op terminal positie (x,y) plaatst. En voor een mooie draaiende animated ASCII cursor, idee gejat van de BSD bootloaders.

Voor zover ik weet begrijpt xterm dat altijd en ziet het er ook altijd hetzelfde uit.
Wat ik wil is met verschillende programma-delen of shellscripts naar dezelfde 'stdout' schrijven en deze vervolgens in zijn geheel op en neer of heen en weer kunnen scrollen, daarbij de content intact latend. Zo onstaat een vloeiende menu/submenu boom waarbij het actieve menu telkens naar het midden van het scherm schuift.

Hoe krijg ik hetzelfde als die printf met UTF-8 voor elkaar? En kan ik zo'n stuk data opgeslagen in UTF-8 formaat ook gewoon naar een terminal gooien, die dat vervolgens correct weergeeft?

Off-topic hiervan maar wat ik me nu wel afvraag is wat voor formaat/standaard de byte-reeksen van pijltjes en andere functietoetsen die je in xterm met fgetc() oid binnenhaalt zijn. Daar lijkt me geen touw aan vast te knopen...

[ Voor 58% gewijzigd door blorf op 27-12-2018 18:57 ]

[Hero of Time]

Nu heb je het opeens over terminal escape tekens. Dat is weer wat anders en is afhankelijk van de terminal en shell die gebruikt wordt of dit fatsoenlijk wordt uitgevoerd. Zou je bash escape sequenties gebruiken in een simpele shell zoals /bin/sh of iets anders als csh of ksh, dan krijg je al andere resultaten. En dan heb je nog niets met de character encoding gedaan.

Ik krijg het idee dat je het hele idee compleet verkeerd bekijkt en zo een incorrecte 'oplossing' gaat krijgen.

Als je tekst of tekens over het scherm wilt laten bewegen, kijk dan eens naar de broncode van 'sl', of ook wel steam locomotive. Het is in Linux een apart commando dat als grap is gemaakt en je apart kan installeren, bedacht voor mensen die vaak 'ls' verkeerd intypen. Dit voor je 'animatie'.

Het plaatsen van tekst is op zich kinderlijk eenvoudig te realiseren. De weergave in een variabele stoppen om later weer op te halen weet ik niet, daarvoor zal je wat verder moeten zoeken.

[hcQd]

@Hero of Time Die escapecodes zijn ook ANSI: ANSI X3.64 om precies te zijn, al is het tegenwoordig een ISO-standaard.

Verder, gebruik curses, daar is het voor. Dit bevat ook de nodige logica om de brij die de toetsen genereren te ontrafelen.

[blorf]

Ik dacht dat escape sequences een ANSI-standaard waren. In DOS had je al ansi.sys nodig voor programma's met automated cursor positioning en zulke dingen. Maar goed, die bedoel ik dus.

En dat het plaatsen van tekst eenvoudig is begrijp ik. Met ncurses heb je een compleet windows-achtig framewerk maar dan enkel op de 256 ASCII reeks gebaseerd. Tegenwoordig kun je er redelijk video in kijken als je een beetje kleine fonts pakt. ^^ Ik wil alleen alles doen met alleen de 1e 128 en geen software layer als curses tussen het programma en de basis I/O. Dan kan ik o.a. weer niet combineren met shellscripts of andere programma's want die kennen de pointer naar het draaiende gedefinieerde curses main-Window niet.

[ Voor 7% gewijzigd door blorf op 27-12-2018 19:59 ]

[Hero of Time]

@hcQd, heb je de quote gelezen die ik had gepost? Er zijn talloze ANSI 'standaarden' waardoor het geen standaard meer is. Dan nog gaat elke shell er anders mee om en ook de terminals doen er andere dingen mee.

[blorf]

Ik vermoed dat het reageren op escape codes in een xterm op gangbare *nix systemen is vastgelegd in POSIX of soortgelijk overkoepelend ding, in o.a. de "xterm" terminal capabilities set en kleurpalet definities en daardoor acceptabel standaard is.
Ooit waren er verschillen in gedrag tussen een xterm een een 80x25 hardwareconsole, ook bij de toetsenbordinvoer. Na de overstap naar vt als systeemterminal zal dat hetzelfde geworden zijn...
Maar om daar nou aan te gaan sleutelen...

Ander voorbeeld van wat ik eigenlijk wil: uit de text output van een bepaald commando een rechthoekje met tekst pakken en die over het scherm rond laten vliegen.
Dat is zelfs in de shell met wat loopjes makkelijk te doen. Maar nu eenzelfde blok tekst maar dan met multi-byte escape-code's voor kleuren en cursor movement erin... Als je zoiets door een pipe stuurt blijft er ook niks van over. Moet ik nu die waarden er letterlijk uithalen, doorberekenen voor de nieuwe positie en terugschrijven, of bestaat er een tool waarmee je escapes bevattende tekst kan manipuleren en schuiven zonder die codes inhoudelijk te moeten veranderen, in ruil voor wat cpu-load?

[ Voor 42% gewijzigd door blorf op 27-12-2018 21:32 ]

[Hero of Time]

Je gaat nu heel erg de programmeer kant op, zonder ook maar iets feitelijks op papier te hebben dat in de basis werkt. Is het wel verstandig om 1001 features en gimmicks te bedenken zonder ook maar een teken aan code te hebben geschreven om te zien of je eerste idee überhaupt wel werkt?

De vragen die je nu stelt passen niet echt in NOS. Maar daar was je zelf ook al achter denk ik.

[blorf]

Ik heb een paar honderd regels, enigzins verweven in een customized FreeBSD "fork", deels C en deels Bash-scripts. Het moet een algemeen systeem menuutje worden voor op zoveel mogelijk verschillende hardware.
Moet ik mijn hele code dumpen? Het gaat mij om het principe of je bestaande statische uitvoer die escape codes bevat kan verplaatsen in een (X) terminal. Is er iets van een virtuele terminal die deze codes accepteert en waar je delen uit kan exporteren naar een zichtbare terminal? Of een utility die een bestand met dergelijke codes ergens anders op het terminal-scherm kan plaatsen waarbij de oorspronkelijke cursor-posities afwijken? In beide gevallen zou er een probleem minder zijn.
Of moet ik dat zelf maken door die escape codes uit elkaar te trekken en te converteren? (waarbij er nieuwe onvoorziene uitzonderingssituaties kunnen ontstaan en een boel werk)

[ Voor 15% gewijzigd door blorf op 27-12-2018 22:56 ]

[Hero of Time]

Je hele code dumpen hoeft niet. Maar heb je iets dat al wel normaal functioneert met wat je in de basis wilt? Krijg je netjes de kleuren te zien ipv escape codes?

[CurlyMo]

Toch nog een andere invalshoek. Je zegt geen ncurses te willen gebruiken, maar voldoet dialog ook niet voor je doel? Dan kan je echt de hele zooi in bash scripten.

Kijk ook eens hoe ik dat ooit modulair opgezet heb voor xbian:
https://github.com/xbianonpi/xbian-config-bash

[ Voor 46% gewijzigd door CurlyMo op 28-12-2018 08:03 ]

[blorf]

Je hele code dumpen hoeft niet. Maar heb je iets dat al wel normaal functioneert met wat je in de basis wilt? Krijg je netjes de kleuren te zien ipv escape codes?

Dat gaan we in de eerste instantie helemaal niet doen. Mag ik jou vriendelijk vragen eens te kappen met die volledig zinloze arrogantie, of anders eens inhoudelijk op te sommen wat je problemen met mij zijn en wat je van plan was daar aan te doen. Dat weten we tenminste waar we aan toe zijn... (Fora waar vooral moderators interessant lopen te doen hebben op mij niet zo'n aantrekkingskracht, we proberen iets te weten te komen)

@Curlymo, dialog ken ik wel enigzins van de ports compile settings, maar kun je een dergelijk venster in een xterm ook een regel of kolom opschuiven zonder de opmaakcode ervan aan te moeten passen? Dat is in de basis waar het me om gaat. Het is mijn bedoeling om een echt interactief menu te maken, met keyboard-input op "non-blocking" dus een delay in de main loop in plaats van wachten op invoer waarbij alles verder stil staat. Technisch gezien moet er uiteindelijk ook veranderlijke status-info of iets dergelijks in dezelfde constructie kunnen werken terwijl de menu-besturing gewoon door draait en actief blijft. Dat werkt nu redelijk, alleen het schuiven met gekleurde tekst en springen naar schermlocaties is nog een probleem omdat dat opmaakdata genest in uitvoerdata is.
Het mooiste zou zijn als het menu met alle mogelijke submenu's en randinformatie op hetzelfde scherm geopend en opgemaakt kunnen worden zonder alles per situatie te moeten converteren met de huidige terminal toestand en afmetingen in acht genomen.

Ik ben overigens al aan het proberen dat zelf te doen, dus mogelijk heb ik het later niet meer nodig.

[ Voor 7% gewijzigd door blorf op 28-12-2018 17:24 ]

[Cyphax]

blorf schreef op vrijdag 28 december 2018 @ 17:17:
[...]

Dat gaan we in de eerste instantie helemaal niet doen. Mag ik jou vriendelijk vragen eens te kappen met die volledig zinloze arrogantie, of anders eens inhoudelijk op te sommen wat je problemen met mij zijn en wat je van plan was daar aan te doen. Dat weten we tenminste waar we aan toe zijn... (Fora waar vooral moderators interessant lopen te doen hebben op mij niet zo'n aantrekkingskracht, we proberen iets te weten te komen)

Dit is jammer. Graag even aandacht voor de volgende twee zaken:

Ik ga ten eerste vriendelijk verzoeken om niet op deze manier om te gaan met anderen; @Hero of Time steekt tijd (vrijwillig) in zijn reacties die bedoeld zijn om je te helpen. Zo'n agressieve houding is altijd onnodig. Doe dat derhalve gewoon niet.


Daarnaast is het op GoT bij programmeervragen niet minder dan gebruikelijk om relevante code te posten. Dat geeft mensen een houvast bij het meedenken en voorkomt suggesties die je al hebt geprobeerd.

Dat laatste zouden ze je waarschijnlijk direct vertellen in het forum waar deze vraag eigenlijk thuishoort: Programming.
Omdat het in het verkeerde forum staat, alsook om de sfeer niet verder te laten afzakken, ga ik dit topic sluiten, en aanraden aan om in Programming de vraag nog eens te stellen. Vergeet dan niet om de code te posten die relevant is voor jouw vraagstuk, en laten we elkander verder respectvol (blijven) behandelen.