TUI interface

[James Harris]

Is there already a good standard way to interface with a textual
display? What I'm looking for is a pre-defined set of calls which I can
just implement rather than having to design from scratch.

For example,

* calls to manage display windows
* calls to manage widgets which go in those windows
* options, for example what to do when a line of text would extend past
the right-hand side of the available space (wrap or not), how to render
a window's borders, what controls a window should have, how elements
should be placed within windows, etc

AISI there are naturally:

Windows which are populated with various widgets

Widgets of various types, each having its own behaviour, which are
placed in windows.

To implement a terminal perhaps a widget could provide a scrollable view
into a text buffer with an input field at the bottom. Not sure.

Ideally, the calls would work whether they were interacting with a TUI
or a GUI so I guess I could follow a GUI standard. But I suspect that
that's getting rather complicated. :-(

Any suggestions?


--
James Harris

[James Harris]

On 14/07/2021 14:56, James Harris wrote:

> Is there already a good standard way to interface with a textual
> display? What I'm looking for is a pre-defined set of calls which I can
> just implement rather than having to design from scratch.

As a sub topic, I gather there are standard ways to implement a
'terminal' which will work with both a VDU and a machine which prints
characters on paper instead of a screen.

For example, with paper a backspace cannot delete the previous character
(unless it's a space) but there are other options. The terminal could:

1. print a certain character to indicate the backspace such as ~ in

prant~~~int

(to form the word "print")

2. back up and overwrite any character which is no longer present in the
buffer as with

pr@@@int

where @ represents some form of overwritten characters.

Similarly, on a VDU a backspace could, effectively, be written as

backspace, space, backspace

but in any case the point is that there's a translation between what a
program would work with (the backspace in this example) and how it gets
rendered on the terminal.

I don't anticipate really using a paper-feed teletype, and backspace is
not the only issue but I would still like there to be a translation
layer between a program and whatever is used as a text-display device.

I know there are various standards for terminals but my experience of
them has - literally for decades - shown that it's difficult if not
impossible for a user to get both ends (OS and terminal) to work
together consistently.

On top of that I gather there are various standards for how terminal IO
translations can be specified - such as what text to print in
bold/bright, where a certain piece of text should appear, how to ask for
a line to be reprinted, etc, but I know almost nothing about them.

Hence the question: would you recommend any particular translation layer
(between OS and the gamut of terminal devices) or would it be better,
these days, to design one's own?


--
James Harris

[Branimir Maksimovic]

Why do you need widgets and what that would be?
>
>


--
bmaxa now listens Ob-Neob Radio

[Branimir Maksimovic]

On 2021-07-14, James Harris <james.h...@gmail.com> wrote:

Terminal just sends escape characters to serial port. OS interprets those
based on termcap file.
Terminal also understands escape characters so that it can move cursor around,\underline,
bold and such. Terminal doesn't connect directly to printer.

[wolfgang kern]

On 14.07.2021 15:56, James Harris wrote:
> Is there already a good standard way to interface with a textual
> display? What I'm looking for is a pre-defined set of calls which I can
> just implement rather than having to design from scratch.

> For example,
>
> * calls to manage display windows
> * calls to manage widgets which go in those windows
> * options, for example what to do when a line of text would extend past
> the right-hand side of the available space (wrap or not), how to render
> a window's borders, what controls a window should have, how elements
> should be placed within windows, etc

doesn't windoze have all these in its API ?

> AISI there are naturally:

> Windows which are populated with various widgets
>
> Widgets of various types, each having its own behaviour, which are
> placed in windows.
>
> To implement a terminal perhaps a widget could provide a scrollable view
> into a text buffer with an input field at the bottom. Not sure.
>
> Ideally, the calls would work whether they were interacting with a TUI
> or a GUI so I guess I could follow a GUI standard. But I suspect that
> that's getting rather complicated. :-(
>
> Any suggestions?

easy to use or easy to make one ? :)

you know I created my own "display-standard" and I made it for easy use,
so there is only one "display it"-instance with a single entry point.
[KESYS FN50 aka "what's on screen"]
The code is therefore somehow complicated because it works on both and
recognises either graphic or text mode and support all formatting you
can think of and allow several fonts simultaneous on screen.

function supports single char, ASCII quads, and formatted strings,
named buttons with 16 border styles and 256 colors also for text mode.
GUI supports pictures, two animated mice and sprites.

finally I removed all mouse support in text mode (because never used).

and it got four output options in addition:
print for printer jobs (modified/buffered to fit attached device)
display goes to screen (as it is)
write goes to a file (as a token/parameter script)
buffer make a copy in RAM (as is for later display)
__
wolfgang

[Alexei A. Frounze]

On Wednesday, July 14, 2021 at 6:56:34 AM UTC-7, James Harris wrote:
> Is there already a good standard way to interface with a textual
> display? What I'm looking for is a pre-defined set of calls which I can
> just implement rather than having to design from scratch.

...

> * calls to manage widgets which go in those windows
> * options, for example what to do when a line of text would extend past
> the right-hand side of the available space (wrap or not), how to render
> a window's borders, what controls a window should have, how elements
> should be placed within windows, etc

If you can find an old book on Turbo Vision or are willing to go through
its code, you may find some answers there.
I think, it was designed pretty well. It was hard to appreciate initially
though, because I mostly saw lots of "stupid" OOP code and boilerplate
stuff that seemed unpleasant and unnecessary (in part, also because
I was working with the Pascal variant, which is wordier than C++).
[Speaking of the stupid OOP, I must say, it's natural for the UI.]
But once you understood more of it, you could see how you could
write stuff that would fit in neatly and benefit from the framework.
Specifically, I'd advise to look at the kind of messages sent between
those widgets and how they were handled.
Objects drawing themselves into various rectangle buffers (visible or
not) is probably more straightforward, even if requires lots of code
and a few tedious pieces here and there with off by one bugs.

Alex

[Rod Pemberton]

On DOS, I coded this stuff myself using the DOS specific <conio.h>
functions. When I ported one DOS app to Linux, I needed to the
<curses.h> functions as there was no <conio.h> for Linux.

So, for *nix, there is the "curses" text GUI library, e.g., ncurses.
There is also the public-domain version, i.e., pdcurses, for DOS etc.

https://en.wikipedia.org/wiki/Curses_(programming_library)
https://en.wikipedia.org/wiki/Ncurses
https://en.wikipedia.org/wiki/PDCurses

To link on Linux,
gcc -lcurses

To use,
#include <curses.h>

Of course, like any graphics library, you have to call all sorts of set
up functions, exit functions, and do a myriad of other stuff ... You'll
need to locate a decent programming guide. E.g. found this for ncurses
via Google:

NCURSES Programming HOWTO
https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/


--
The Chinese have such difficulty with English ... The word is not
"reunification" but "revenge".

[Rod Pemberton]

needed to use the

> So, for *nix, there is the "curses" text GUI library, e.g., ncurses.
> There is also the public-domain version, i.e., pdcurses, for DOS etc.
>
> https://en.wikipedia.org/wiki/Curses_(programming_library)
> https://en.wikipedia.org/wiki/Ncurses
> https://en.wikipedia.org/wiki/PDCurses
>
> To link on Linux,
> gcc -lcurses
>
> To use,
> #include <curses.h>
>
> Of course, like any graphics library, you have to call all sorts of
> set up functions, exit functions, and do a myriad of other stuff ...
> You'll need to locate a decent programming guide. E.g. found this
> for ncurses via Google:
>
> NCURSES Programming HOWTO
> https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/
>

Hey, were you the guy that liked Python?

Curses Programming with Python
https://docs.python.org/3/howto/curses.html

[James Harris]

Not sure what you mean. Widgets would support user interaction. See
https://en.wikipedia.org/wiki/Graphical_widget#List_of_common_generic_widgets
for examples.


--
James Harris

[James Harris]

On 15/07/2021 02:54, Rod Pemberton wrote:
> On Wed, 14 Jul 2021 14:56:31 +0100
> James Harris <james.h...@gmail.com> wrote:
>
>> Is there already a good standard way to interface with a textual
>> display? What I'm looking for is a pre-defined set of calls which I
>> can just implement rather than having to design from scratch.

...

> On DOS, I coded this stuff myself using the DOS specific <conio.h>
> functions. When I ported one DOS app to Linux, I needed to the
> <curses.h> functions as there was no <conio.h> for Linux.
>
> So, for *nix, there is the "curses" text GUI library, e.g., ncurses.
> There is also the public-domain version, i.e., pdcurses, for DOS etc.
>
> https://en.wikipedia.org/wiki/Curses_(programming_library)
> https://en.wikipedia.org/wiki/Ncurses
> https://en.wikipedia.org/wiki/PDCurses

Thanks, I've been looking at curses and it seems very 'mechanical'.

For example, the placement of windows and the cursor movements are very
specific. Such commands may not work if the user resizes the view window.

I think I need a higher level of commands such as

* place these widgets on the window in this order
* this widget is a container for these other widgets

Then if the window's height or width are changed the widget can be
relocated and/or resized and the same widgets will still be there.

One might be able to do away with the concept of a window and just have
a 'widget' which provides the features of a window; then "everything
would be a widget".

>
> To link on Linux,
> gcc -lcurses
>
> To use,
> #include <curses.h>
>
> Of course, like any graphics library, you have to call all sorts of set
> up functions, exit functions, and do a myriad of other stuff ... You'll
> need to locate a decent programming guide. E.g. found this for ncurses
> via Google:
>
> NCURSES Programming HOWTO
> https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/

Thinking of the terminal itself, do you have a view on what 'modes' a
terminal ought to support? AISI:

* One possible mode is the plain glass teletype. Every character the
system prints goes at the bottom. Every non-password character the user
types also goes at the bottom. That could mix up system and user output
so the user might need a command such as Control+R to retype the current
input line.

* Another mode is the two-buffer teletype. There would be a main buffer
to which the system writes - probably whole lines at a time - and
another buffer below that on the screen in which what a user types is
assembled. Once the user commits the line by pressing the Enter key the
line is transferred to the bottom of the main buffer.

Both of those scroll up as new content is added at the bottom.

* Another useful mode is with no scrolling but essentially fullscreen.
The Unix 'less' command is a good example of this. If one runs something
like

$ less file.txt

then file.txt is displayed in the full window but after viewing the file
one is returned to the command prompt with the screen showing

$ less file.txt
$

Similar could be said of a full-screen editor.

I don't know if there are any other useful modes.

I wonder if a 'widget' could provide the terminal interface with those
modes.

No need to reply unless you want to. I guess this is something I'll just
have to keep working through.


--
James Harris

[James Harris]

On 14/07/2021 21:51, wolfgang kern wrote:
> On 14.07.2021 15:56, James Harris wrote:
>> Is there already a good standard way to interface with a textual
>> display? What I'm looking for is a pre-defined set of calls which I
>> can just implement rather than having to design from scratch.
>
>> For example,
>>
>> * calls to manage display windows
>> * calls to manage widgets which go in those windows
>> * options, for example what to do when a line of text would extend
>> past the right-hand side of the available space (wrap or not), how to
>> render a window's borders, what controls a window should have, how
>> elements should be placed within windows, etc
>
> doesn't windoze have all these in its API ?

Probably. But I guess there would be more than a little to implement. :-(

There are also issues with it, IIRC. For example, if a child widget has
registered to receive KEYDOWN events then it will get them even for
events which are handled as a KEYPRESS event for a parent widget.

>
>> AISI there are naturally:
>
>> Windows which are populated with various widgets
>>
>> Widgets of various types, each having its own behaviour, which are
>> placed in windows.
>>
>> To implement a terminal perhaps a widget could provide a scrollable
>> view into a text buffer with an input field at the bottom. Not sure.
>>
>> Ideally, the calls would work whether they were interacting with a TUI
>> or a GUI so I guess I could follow a GUI standard. But I suspect that
>> that's getting rather complicated. :-(
>>
>> Any suggestions?
>
> easy to use or easy to make one ? :)

Both, naturally!

>
> you know I created my own "display-standard" and I made it for easy use,
> so there is only one "display it"-instance with a single entry point.
> [KESYS FN50 aka "what's on screen"]

I'd forgotten that you'd done that. I fear that's what I'll have to do.
Would you recommend your system and is the API published?

> The code is therefore somehow complicated because it works on both and
> recognises either graphic or text mode and support all formatting you
> can think of and allow several fonts simultaneous on screen.

Having the same interface whether the display is TUI or GUI is exactly
what I want, at least in the long term, though I'd prefer if there was
an easy way to start off.


--
James Harris

[wolfgang kern]

On 17.07.2021 20:02, James Harris wrote:
...

>>> Any suggestions?
>> easy to use or easy to make one ? :)
> Both, naturally!

hard to get both :)

>> you know I created my own "display-standard" and I made it for easy use,
>> so there is only one "display it"-instance with a single entry point.
>> [KESYS FN50 aka "what's on screen"]

> I'd forgotten that you'd done that. I fear that's what I'll have to do.
> Would you recommend your system and is the API published?

I wont recommend to do it exactly my way, because it's pretty uncommon
and uses code parts as variables for self-modify on resolution changes.
the API were only "published" to a handful members but it is logical
ordered in function groups, I can show a few examples here.

FN50 has four entry points RM/PM16, PM32, INT7F(RM), INT7F(PM16).
input: AL=data(1) AH=0x50 eaxlhb=subfn(2) eaxhhb=(data3)
eDX(text pos4 row/col) eCX(hor5) eBX=(ver6)
1) char, color,line pattern, border style, and more...
2) 256 functions where some have many subfunctions:
text,buttons,captions,lines,rectangles,circles ,,,,
Dot-modes(forg and back): PUT, AND, ADD, OR, XOR, transparent
Text format: LSET,RSET,Centered,TABset
NUMeric format: LSET,Tabset,Menu Tabset,DP-aligned,field aligned
colorbox, numeric and text input fields, editable named bit arrays
dual Font set with any dot-mode (Bold, sub, sup, inverse)
text pages, graphic pages, vertical scroll,
dual mouse, animated sprites, bitmaps (non M$ format)
3) additional data like circle aspect ratio or graphic parameter
4) text numeric and input field position use row/column in graphic too
5) 6) graphic elements size(s) position is in global graphic vars then.

>> The code is therefore somehow complicated because it works on both and
>> recognises either graphic or text mode and support all formatting you
>> can think of and allow several fonts simultaneous on screen.

> Having the same interface whether the display is TUI or GUI is exactly
> what I want, at least in the long term, though I'd prefer if there was
> an easy way to start off.

a single bit which tells G or T (re)set when the mode change is enough.
it isn't only one interface but many common things can be shared.
__
wolfgang

[Rod Pemberton]

On Sat, 17 Jul 2021 10:56:54 +0100

James Harris <james.h...@gmail.com> wrote:

> On 15/07/2021 02:54, Rod Pemberton wrote:
> > On Wed, 14 Jul 2021 14:56:31 +0100
> > James Harris <james.h...@gmail.com> wrote:

> >> Is there already a good standard way to interface with a textual
> >> display? What I'm looking for is a pre-defined set of calls which I
> >> can just implement rather than having to design from scratch.
> >

> > So, for *nix, there is the "curses" text GUI library, e.g., ncurses.
> > There is also the public-domain version, i.e., pdcurses, for DOS
> > etc.
> >
>

> Thanks, I've been looking at curses and it seems very 'mechanical'.

You might need some other TUI library then, or you can go way more
advanced like libSDL. There should be a few TUI libraries still
available for DOS. I'm not sure about Linux. Wikipedia's TUI article
mentions CDK library and Turbo Vision. There might be some old TUIs
hanging around in the DJGPP, or Simtel, or Garbo, or SAC, or FreeDOS
archives too.

> > ...

> >
> Thinking of the terminal itself, do you have a view on what 'modes' a
> terminal ought to support?

No, not really.

As long as text is displayable, in either text or graphics mode, then I
can use my personal C programs, or C compiler tool chains, or a text
editor, etc. Otherwise, for non-programming, a web browser and office
suite will suffice.

But, if I was coding a terminal emulator, I'd pick VT220 or VT102.
Emulation of those two terminals was common during the BBS era, even
for non DEC equipment.

> [modes]

>
> Both of those scroll up as new content is added at the bottom.

Were you aware that the BIOS can set a text scroll window for BIOS text
modes?

RBIL INT 10 - VIDEO - SCROLL UP WINDOW
http://www.delorie.com/djgpp/doc/rbinter/id/01/1.html

I use it when tracing BIOS and DOS interrupts to display some of the
processor registers in a narrow scrollable window on the right hand side
of the screen. But, of course, you could use it to set up and clear
out text menus, except that is rather low-level too.