Outcurses

(5 intermediate revisions by the same user not shown)

Line 1:

[[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/~~outcurses~~ github].

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.

This project led to [[notcurses]].

==Palette fades==

Line 285:

Line 287:

This would seem strong support for snapshots. The size would theoretically be unbounded (i.e. copy output of the object assuming an infinite tablet), but it seems we could bind it to the total size of the screen. This runs into some details that seem possible to overcome (what if a new, larger display is attached to the machine during runtime, and the window is moved to that screen, and maximized?). The fatal problem in my mind is that these non-trivial (if bounded) copies must be performed for all interfaces, whether on-screen or off-. So far as I can tell, any scheme which avoids copies for off-screen tablets requires a locked callback into the core, since a UI event can bring a tablet on-screen independently of any core event. Since there is an unbounded number of off-screen interfaces needing copies, the overall copying can once more be unbounded, and thus the snapshot approach is unacceptable. Notifications it is, then.

The problem with notifications is primarily that objects can be removed by the core while the UI still holds references to them. The UI blindly invoking these objects will result in catastrophe. We can add a reference count to the objects, at the cost of some application complexity (the application must down the reference counter, and provide a destructor that can be called from UI context). Avoiding this complexity in the application seems to require substantial complexity in outcurses: the application can be allowed to freely destroy its object following posting notification of the deletion if outcurses takes this into consideration when performing other actions. For instance, prior to user keypress selecting the previous tablet, it must be verified that this tablet still exists. If the move pushes some other tablet partially off-screen, it must be verified that this other tablet still exists prior to redrawing it, etc. In the case where the tablet no longer exists, action must be taken to remove it (and fill the void) along all manner of new control flow paths.

The problem with notifications is primarily that objects can be removed by the core while the UI still holds references to them. The UI blindly invoking these objects will result in catastrophe. We can add a reference count to the objects, at the cost of some application complexity (the application must down the reference counter, and provide a destructor that can be called from UI context). Avoiding this complexity in the application seems to require substantial complexity in outcurses: the application can be allowed to freely destroy its object following posting notification of the deletion if outcurses takes this into consideration when performing other actions. For instance, prior to user keypress selecting the previous tablet, it must be verified that this tablet still exists. If the move pushes some other tablet partially off-screen, it must be verified that this other tablet still exists prior to redrawing it, etc. In the case where the tablet no longer exists, action must be taken to remove it (and fill the void) along all manner of new control flow paths. Alternatively, the callback could require a core lookup each time.

==Panel animations==

Line 294:

Line 296:

* The Python [https://docs.python.org/2/library/curses.panel.html curses.panel] module

* My [[Xcurses]] project, which went exactly nowhere

* [http://www.leonerd.org.uk/code/libtickit/ libtickit]

[[CATEGORY: Projects]]

[[CATEGORY: Terminals]]

Outcurses: Difference between revisions

Dank (talk | contribs)

@@ Line 1: / Line 1: @@
 [[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/outcurses github].
+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.
+This project led to [[notcurses]].
 ==Palette fades==
@@ Line 285: / Line 287: @@
 This would seem strong support for snapshots. The size would theoretically be unbounded (i.e. copy output of the object assuming an infinite tablet), but it seems we could bind it to the total size of the screen. This runs into some details that seem possible to overcome (what if a new, larger display is attached to the machine during runtime, and the window is moved to that screen, and maximized?). The fatal problem in my mind is that these non-trivial (if bounded) copies must be performed for all interfaces, whether on-screen or off-. So far as I can tell, any scheme which avoids copies for off-screen tablets requires a locked callback into the core, since a UI event can bring a tablet on-screen independently of any core event. Since there is an unbounded number of off-screen interfaces needing copies, the overall copying can once more be unbounded, and thus the snapshot approach is unacceptable. Notifications it is, then.
-The problem with notifications is primarily that objects can be removed by the core while the UI still holds references to them. The UI blindly invoking these objects will result in catastrophe. We can add a reference count to the objects, at the cost of some application complexity (the application must down the reference counter, and provide a destructor that can be called from UI context). Avoiding this complexity in the application seems to require substantial complexity in outcurses: the application can be allowed to freely destroy its object following posting notification of the deletion if outcurses takes this into consideration when performing other actions. For instance, prior to user keypress selecting the previous tablet, it must be verified that this tablet still exists. If the move pushes some other tablet partially off-screen, it must be verified that this other tablet still exists prior to redrawing it, etc. In the case where the tablet no longer exists, action must be taken to remove it (and fill the void) along all manner of new control flow paths.
+The problem with notifications is primarily that objects can be removed by the core while the UI still holds references to them. The UI blindly invoking these objects will result in catastrophe. We can add a reference count to the objects, at the cost of some application complexity (the application must down the reference counter, and provide a destructor that can be called from UI context). Avoiding this complexity in the application seems to require substantial complexity in outcurses: the application can be allowed to freely destroy its object following posting notification of the deletion if outcurses takes this into consideration when performing other actions. For instance, prior to user keypress selecting the previous tablet, it must be verified that this tablet still exists. If the move pushes some other tablet partially off-screen, it must be verified that this other tablet still exists prior to redrawing it, etc. In the case where the tablet no longer exists, action must be taken to remove it (and fill the void) along all manner of new control flow paths. Alternatively, the callback could require a core lookup each time.
 ==Panel animations==
@@ Line 294: / Line 296: @@
 * The Python [https://docs.python.org/2/library/curses.panel.html curses.panel] module
 * My [[Xcurses]] project, which went exactly nowhere
+* [http://www.leonerd.org.uk/code/libtickit/ libtickit]
 [[CATEGORY: Projects]]
+[[CATEGORY: Terminals]]