home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.development      Operating system development chatter      4,255 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 2,594 of 4,255   
   wolfgang kern to James Harris   
   Re: TUI interface   
   14 Jul 21 22:51:22   
   
   From: nowhere@never.at   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca