On Fri, Oct 26, 2012 at 01:56:28PM +0200, Tobias Pankrath wrote: > On Tuesday, 23 October 2012 at 22:47:40 UTC, Walter Bright wrote: [...] > >A more comprehensive module that included: > > > >1. getting mouse input > >2. getting size of the console > >3. moving the cursor around > >4. drawing boxes in the console window > >5. setting the contents of the title bar > >6. supporting cut/paste > >7. getting no-echo raw input > >8. setting the size of the cursor > > > >would be a definite candidate. I.e. a module that can support > >building a text mode screen app (like a text editor). > > This would look like a full blown TUI-Toolkit and we should model the > API after successfull GUI-Frameworks like Qt, i.e. provide a event > loop, use a Signal/Slot mechanism etc.
If we implement an event loop, I think it should be optional. Many apps only need to do simple things like allow editing operations on the current input line (support backspace, insert, delete, moving cursor left/right, etc.). Having a full-blown event loop is overkill. OTOH, having the *option* of using an event loop makes it easier to write things like network-based apps, where input from many different directions can be handled asynchronously. It also makes it possible to "skin" an app to work with both GUI and TUI if the underlying code is pretty much the same, except for different low-level calls at the bottom. :) So I think it's a good thing to have. Just make it optional, not mandatory. > That would be a real improvement over nCurses. What do you think? [...] Anything that improves on ncurses is welcome by me. Although ncurses does what it does very well, the API is a poorly-designed patchwork of functions that overlap too much in some areas, and not enough in others. (Try UTF-8 processing on ncurses sometime. Or maybe, _don't_, because it leads to pain and suffering.) Having a well-designed, consistent API would be a major plus. T -- You have to expect the unexpected. -- RL
