Buffered versus direct drawing

[peterbrittain]

At the lowest level, the Screen class enforces a refresh() before it will draw anything. This is irritating for people who just want to do some simple drawing. Consider providing 2 modes of operation for the class:

1. Buffered - bascially the current mode, but fully enforcing double buffering.
2. Direct - which will draw directly and so have no refresh required.

Some interesting decisions need to be made in both cases:

1. Whether to clear the screen or not at start up? Possibly direct mode should leave that up to the user?
   • Also may be limited by what I can do to keep mouse support (through ncurses). See http://stackoverflow.com/questions/4772061/how-do-i-use-getch-from-curses-without-clearing-the-screen
2. Whether to expose the current cursor position or not? Makes less sense in buffered mode.
3. Whether to allow screen character look-ups? Doesn't makemuch sense if the screen isn't reset to a known state (i.e. cleared) at start-up.

It feels like these may behighly related, but ultimately different class implentations...

[peterbrittain]

Requires new API that is being proposed for v2.0

[peterbrittain]

Might need current cursor position. Looks like this uses u6-7. See http://unix.stackexchange.com/questions/239271/parse-terminfo-u6-string

[peterbrittain]

Windows cursor pos from https://msdn.microsoft.com/en-us/library/windows/desktop/ms683171(v=vs.85).aspx

[peterbrittain]

Also need to think about relative movement inthis environment - e.g. start of line, up/down one line, etc. That may be possible with a print method instead of print_at. But if I do that, can I still support renderers using paint? Maybe the correct API is to provide no print_at for direct mode and to make paint work from the current cursor pos?

[peterbrittain]

It appears that I can only really use setupterm() in curses and so have to limit available function (e.g. no input at all). That means an API like:

• print_at
• centre
• palette
• paint
• highlight
• dimensions (using "cols" and "lines" from terminfo)
• is_visible

Plus some other methods that might now make sense if I can break out the classes neatly enough:

• save/restore cursor position (using "sc"/"rc")
• hide cursor (using "civis"/"cnorm")
• fullscreen (using "smcup"/"rmcup")
• clear (using "clear")
• get_current_pos (using "u6"/"u7") - though it's not obvious this is supported on all terminals.

Longer term it might be possible to do the following (but they will be messy to fit into the current APIs):

• print (with relative positions [see cup, hpa and vpa] and colours?)
• cursor movement (with relative motion? - see cub1, cuf1, cuu1, cud1)
• Possibly print_renderer to simplify use of such things...

[peterbrittain]

A little more research on how dialog simply overrides stuff inside ncurses leads me to believe that I might be able to use the rmcup sequence on curses systems to allow full interaction with the normal screen. Feels a bit hacky, but could be a way forwards.

[peterbrittain]

Need to look at resizing and extracting state of screen before the app starts a little more closely, but a quick trial script looks like this could give full cursor control and keyboard input, thus giving access to the full existing API.