From: james.harris.1@gmail.com   
      
   On 15/07/2021 02:54, Rod Pemberton wrote:   
   > On Wed, 14 Jul 2021 14:56:31 +0100   
   > 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.   
      
   ...   
      
   > On DOS, I coded this stuff myself using the DOS specific    
   > functions.  When I ported one DOS app to Linux, I needed to the   
   >  functions as there was no  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    
   >   
   > 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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)