Proposal: A bufferless/lowlevel version

[vuurrobin]

Hello,

First of all, thanks for creating tcell. I can see that a lot of time and effort went into creating this and it looks like feature complete for its intended goal of creating fullscreen TUI programs.

That got me thinking about what it would take to support programs that doesn't need or want full screen. Looking at the code, all implementations use baseScreen for some of the more common functions and an implementation of the screenImpl interface for the actual communication with the terminal as well as containing the CellBuffer struct.

My idea would be to change screenImpl so its implementations only have a pretty low level api for the terminal, not force any specific setting like alternate screen mode and move the CellBuffer struct to baseScreen. baseScreen can then use screenImpl as well as the CellBuffer to implement the current tcell api for fullscreen TUI programs. By making screenImpl useable on its own (maybe put it in a seperate package/subdirectory), people can use that directly if they are creating a program that isn't fullscreen. I would also expose the screenImpl through baseScreen (and the Screen interface) so that people that use that can still access the lower level api and even send custom codes to the terminal. The Tty() method on Screen already does something similar, but it returns nil on windows making it less usefull.

I created a fork and implemented how a low-level terminal api would look like in my opinion. It can be found here: https://github.com/vuurrobin/tcell/tree/bufferless/bufferless
It currently only has a windows implementation and I made it partly for learning and research, so nothing is set in stone just yet.

The primary reason I'm making this issue is to see if you are interested in this @gdamore and if so, what would be the best way forward to implement this. You spoke of a v3 over a year ago, I don't know what the status is of that, but maybe this can be a part of this. I'd love to get your input on this.

Kind regards,
Robin

[gdamore]

I'm still a little unclear about how you would expect a "bufferless" implementation to be used. Tcell is all about updating an X/Y location, and redrawing it. Do you just not want the double buffer but direct console access? You'd then have to be responsible for anything non-trivial such as the optimizations to write only what is changed, etc.

[vuurrobin]

Yes, my goal would be more direct console access. Not just for writing to it, but also for things like choosing whether the terminal is in alternate screen mode or whether input gets echo'd back to the terminal. This means more responsibility for the one using it, but it would also open up possibilities like a readline/readpassword function, progress bars etc.

This would indeed be outside the original scope of tcell, so I would understand if you don't want to go this route. But considering how much time and effort already wend in tcell, replicating that in a separate library would most likely result in a duplication of maintainance efforts.

Plus if this is added and tcell itself would allow access to it, then people can use tcell normally for all supported functionality, but allow a way for people to handle unsupported functionality itself. For instance on a terminal that supports images, people can use that by sending the correct terminal sequences themselfs. This is already somewhat supported with the Tty() method, but that always returns nil on windows.