notes on API improvements

[c-cube]

• put everything in a single module Nottui (easily aliasable/openable). I'll refer to it as UI from now on.
• re-export Lwd as UI.Incremental and Lwd_seq as UI.Seq
• UI.Syntax with let$ and other bind/map from Lwd, along with UI helpers like <|> or <-> for h/v concatenation of UI elements
• everything returns lwd-wrapped UI elements. I think UI.t = UI.Pure.t Lwd.t would make a lot of sense (where UI.Pure.t can be the base type for non-reactive elements). Most functions will work on lwd-wrapped things.
• commonly used functionality is re-exported at toplevel in UI, for example UI.s for a string widget, UI.space, UI.sprintf, hcat (list), hjoin (binary horizontal concat), <|> (alias for hcat)
• widgets can have their own submodule with all the bells and whistles (maybe as objects?), + a toplevel function to build them easily (like UI.Scrollable for the whole thing, along with a UI.scrollable : … function for the common case)
• re-export pretty as UI.Pretty (can be just a module alias for lightweightness)

minor quibbles

• flex needs more testing (but would be useful to keep)
• scrollable currently doesn't take as much space as it can, so only the used part is actually scrollable

also see #5 for a bigger wishlist :horse: :santa: :gift:

[let-def]

Other notes:

• Nottui would benefit from scheduling callbacks to execute at specific time: before next frame or after a certain delay (animation / popover) (alternative is to use Lwt, but that's overkill, the Nottui mainloop can take care of that)
• To implement "hover" we need support for raw terminal mode and more escape codes
• Nottui "overlay" system needs a new implementation, supporting popups, modal dialogs, etc.
• Basic widget set needs to be revisited, probably drawing inspiration from Imgui
• Sensors and maybe scrolling primitives are a bit wonky, redesign them
• Drag'n'drop / mouse grabbing and event handling is too low-level

(Good point: all these changes concern Nottui, not Lwd :smile:)

[c-cube]

to handle theming, maybe a reactive map type would be useful (config_flag Lwd_string_map.t or something like that?) so that each config key can be changed dynamically, and the UI uses the key's value incrementally.

I mean:

type config
val get : config -> string -> config_flag Lwd.t

with a bunch of theming keys.

[let-def]

On theming: wouldn't a list of global variables be enough? Do we need a dynamic map?

[c-cube]

what if you want two UIs with distinct themes? but yeah, that sounds far fetched. :+1:

[let-def]

The problem then is not whether the map is dynamic, but how to scope it. Should on thread the control value manually when building the UI?

Or should we add dynamic scoping primitives to Lwd? (Nope, that would complicate the theory significantly, although the symmetry with Lwt thread local storage is somewhat funny :P)

[c-cube]

There's got to be downward flowing information in nottui, isn't there? About terminal size, for example (or available space for a component to render). Configuration could also be passed along.