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