>From the discussion so far it seems to me that a few conclusions that can be
>reached, and that there are existing packages that can be used, or enhanced,
>or stolen from (nimmed?), to give us a good start on implementation:
* The need to accommodate both "retained" (queued with polling) and
"immediate" (non-queued, no polling) event processing puts constraints on the
underlying graphics library. Immediate mode can be converted to retained mode
simply by having it feed a queue that is drained in a different thread. But
retained mode cannot be converted to immediate mode.
* This precludes sdl2, which uses a polling (i.e. queued) event mechanism.
* So the choice is glfw, which uses a callback (non-queued) mechanism.
Multithreading can be supported by having the callback(s) either generate
asynchronous messages or feed an event queue.
* This points to fidget (and relevant tweaks from the cloned version in
fidgetty) as a starting point for this.
* The need for multithreaded operation also puts constraints on the code for
processing in the other direction, i.e. output to the display. As @thindil
pointed out, opengl does not support multithreading. This means that all calls
to opengl (and glfw?) must be done from a single thread. Which in turn means
that drawing/rendering a UI element's contents must be separated from calls to
opengl.
* In other words, drawing/rendering a UI element's image would occur in the
same thread as the element's event processing. But output to the display must
be accomplished by queueing the rendered image to the single thread that calls
opengl for output to the display.
* I suggest that pixie is the natural choice for the image rendering part,
including fonts.
* Dealing with layouts must be available from within Nim. This doesn't
preclude the use of things like a Figma plugin, but generating an application's
UI layout must not be dependent on it. I suggest fidgetty and its use of
cssgrid as a start for this.
* Both fidgetty and nimx implemented a layout DSL. I suggest that this
approach could be the lowest-level API layer for this, with support for
NimScript (which I know nothing about), etc. to be added later.
* I believe that OO would be useful for the widget hierarchy. I haven't
looked at its code in any detail, but nimx does use OO for its widgets. And I
liked what I saw in my brief browse of the hierarchy documented in Godot.
There is a bunch of work to be done - as @elcritch pointed out, text processing
is a major missing pre-requisite for a viable UI library. And a canvas widget
is needed for any application that generates plots. But we are not starting
from zero.
