Outcurses: Difference between revisions
No edit summary |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[File:OUTCURSES.png|right|thumb|bling up that terminal]] | [[File:OUTCURSES.png|right|thumb|bling up that terminal]] | ||
During the development of [[Growlight]] and [[Omphalos]], I found myself implementing significant UI code atop [[ncurses]]. It's my goal to extract most of this, unify it, and make it available as liboutcurses. Code lives on [https://github.com/dankamongmen/ | During the development of [[Growlight]] and [[Omphalos]], I found myself implementing significant UI code atop [[ncurses]]. It's my goal to extract most of this, unify it, and make it available as liboutcurses. Code lives on [https://github.com/dankamongmen/panelreels github]. | ||
Why is it called 'outcurses'? Because there's [https://www.collinsdictionary.com/us/dictionary/english/outcurse more cursing], duh. | Why is it called 'outcurses'? Because there's [https://www.collinsdictionary.com/us/dictionary/english/outcurse more cursing], duh. | ||
This project led to [[notcurses]]. | |||
==Palette fades== | ==Palette fades== | ||
| Line 265: | Line 267: | ||
For Outcurses and its general-purpose panelreels, we cannot assume deep application assistance. We cannot assume understanding of application internals. We cannot assume that it is possible to cache structure beyond the circular list of top-level objects corresponding to tablets, and we cannot even assume this last to be truly reflected in the application, which might very well not have a concept of ordering among the tablets. Furthermore, it would be a fine thing indeed to wholly decouple screen updates from any locked core code. | For Outcurses and its general-purpose panelreels, we cannot assume deep application assistance. We cannot assume understanding of application internals. We cannot assume that it is possible to cache structure beyond the circular list of top-level objects corresponding to tablets, and we cannot even assume this last to be truly reflected in the application, which might very well not have a concept of ordering among the tablets. Furthermore, it would be a fine thing indeed to wholly decouple screen updates from any locked core code. | ||
Accomplishing this last eliminates almost all of our problems, while introducing a few new ones. Decoupling screen updates from core updates means that UI code cannot be called from any application context holding core locks. This immediately suggests a producer/consumer model where updates are written to a shared, synchronized buffer. In a model where data is copied to the UI state (and thus it needn't lock against the core), these updates might take the form of piecemeal instructions ("iface 2 has added a subelement. iface 3 has received the following packet." etc.), and it would be necessary to process the updates in-order and cumulatively, though actual screen redrawing could be postponed to the end of a batch of updates. Alternatively, the entirety of state could be copied for each update, eliminating complexity in both the UI and core for a price paid in memory and time. Finally, nothing could be published save "iface 2 has changed", requiring a locked call into the core to get the data (and reference counters for data which might be destroyed). Comparing these strategies, we see: | Accomplishing this last eliminates almost all of our problems, while introducing a few new ones. Decoupling screen updates from core updates means that UI code cannot be called from any application context holding core locks. This immediately suggests a producer/consumer model where updates are written to a shared, synchronized buffer. In a model where data is copied to the UI state (and thus it needn't lock against the core), these updates might take the form of piecemeal instructions ("iface 2 has added a subelement. iface 3 has received the following packet." etc.), and it would be necessary to process the updates in-order and cumulatively, though actual screen redrawing could be postponed to the end of a batch of updates. Alternatively, the entirety of state could be copied for each update, eliminating complexity in both the UI and core for a price paid in memory and time. Finally, nothing could be published save "iface 2 has changed", requiring a locked call into the core to get the data (and reference counters for data which might be destroyed). Comparing these strategies, we see: | ||
| Line 294: | Line 296: | ||
* The Python [https://docs.python.org/2/library/curses.panel.html curses.panel] module | * The Python [https://docs.python.org/2/library/curses.panel.html curses.panel] module | ||
* My [[Xcurses]] project, which went exactly nowhere | * My [[Xcurses]] project, which went exactly nowhere | ||
* [http://www.leonerd.org.uk/code/libtickit/ libtickit] | |||
[[CATEGORY: Projects]] | [[CATEGORY: Projects]] | ||
[[CATEGORY: Terminals]] | |||