[RFC] ColorD

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Oct 26 11:07:11 PDT 2012


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


More information about the Digitalmars-d mailing list