solent-eng / solent

Free software sequencer architecture
GNU Lesser General Public License v3.0
7 stars 4 forks source link

Focus the console #68

Open cratuki opened 7 years ago

cratuki commented 7 years ago

Currently we have a package term and a package console. This was one of the earliest areas of code, and dates from when this codebase was a roguelike game that happened to have some async code in it, and before it got its async focus.

There is a lot of cleanup opportunity.

// Marginalise term

Term was intended to be a standard terminal that runs over console. For example, offering a standard selection interface. However, it's confusing having both of them. I had an idea that the selection feature would be useful for writing a xcom-like game. So far, I have had no use for it. For the moment, we would be better off if we marginalised that as utility rail.

// Simplify console interface

Parts of console predate solent. It contains some functionality that is out-of-place here, such as blocking IO. This could be simplified.

// Remove pygame from solent

Further, at the moment console's pygame mode requires an external dependency. Pygame is a large package with awkward install arrangements on every setting. The ideal would be if we had curses be default on unix, with an equivalent native-Windows-interface to be default on win32. With no dependencies. It's totally do-able, but would require work (windows systems programming, from python, with no external dependencies). It seems to be possible to make calls directly from ctypes. Starting points (https://github.com/erochest/snippets/blob/master/win32named.py) (http://stackoverflow.com/questions/1057496/how-to-do-windows-api-calls-in-python-3-1). Leaving this for now, focus on making unix usage right.

Pygame should be moved out of solent into a related package, such as solent_console_pygame. There'd be separate packaging arrangements for this.

// Summary

Work

cratuki commented 7 years ago

Getting rid of block_get_keycode is awkward. Currently the platform does offers select(2) only across network sockets, and not across local files or stdin. As a result, keystroke interaction is sluggish. Hence, as inelegant as block_get_keystroke is, it is currently the only way to offer responsive UI. This is a major limitation of the current platform.

I've sketched out the work that would be involved with an overhaul of the engine to move beyond this.

I'm going to tweaks I have done towards this issue. Further work depends on the engine overhaul.

cratuki commented 7 years ago

// Status The commit I just made has achieved some of this work. As above, it is not worth spending more time on the console until we have created a next-gen engine that will allow us to asynchronously scan for user keypress activity.

// Done Refactor spin_term to solent.util.spin_selection_ui. Get rid of package term

// Future Remove block_get_keycode (requires a new SelectEngine) Refactor console in its current form to follow callback/callstruct conventions Simplify console interface by deleting keystream. Instead focus console on cb_async_get_keycode Refactor console so that there is a default console (rather than it being controlled by an init argument, this should adapt to the local platform.). Remove pygame functionality from solent core. (Probably by moving it to an external library)

cratuki commented 6 years ago

Depends on #107

Some of the text here will be obsolete once we are through that. However, some significant thinking went into this ticket. I should review it at a time after 107.