From: james.harris.1@gmail.com   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)