yampa-gui: Nested Dynamic Windowing System Library

[Cajunvoodoo]

Inspired by windowing systems like Xmonad and the GUIs of the Yampa arcade, a robust, extensible, and dynamic windowing system would be a great addition to Yampa's capabilities.

I came up with a rough plan of capabilities a window must have along with a number of hurdles.
Capabilities:

1. A window responds to inputs and passes that to its children
2. A window can be focused or unfocused to allow for routing input correctly
3. Windows may be arbitrarily nested and have arbitrarily many children (that are also windows)
4. A window may output events to the parent (like destruction and creation of self and siblings respectively) or for more complex behavior
5. A window may have zero children (e.g. a button or a text box) and can hold data relevant to its function
6. A window must have a Picture element (yampa-gloss) that describes its appearance

When I was thinking it over, windows reminded me of dpSwitch. The hurdle I came across was routing and the nested nature of windows; how do we nest dpSwitches (child windows) inside another dpSwitch (the parent window)?

Another conceptual challenge i came across was data relevant to specific children. Here's a contrived but salient example:

┌──────────────────────────────────────┐
│  ┌────────────────────────────────┐  │
│  │          Count: n              │  │
│  ├────────────────┬───────────────┤  │
│  │                │               │  │
│  │   I'm a blank  │               │  │
│  │     window!    │               │  │
│  ├────────────────┤               │  │
│  │                │               │  │
│  │ ┌────────────┐ │  ┌──────────┐ │  │
│  │ │┼──────────┼│ │  │          │ │  │
│  │ ││          ││ │  │ Bigger   │ │  │
│  │ ││Big Button││ │  │ Button   │ │  │
│  │ ││ Click to ││ │  │ Click to │ │  │
│  │ ││ Decrement││ │  │ Increment│ │  │
│  │ ├┴──────────┴┤ │  │          │ │  │
│  │ │            │ │  │          │ │  │
│  │ │ Also Empty │ │  └──────────┘ │  │
│  │ ├────────────┤ │               │  │
│  │ │  Empty! :3 │ │               │  │
│  │ └────────────┘ │               │  │
│  │                │               │  │
│  └────────────────┴───────────────┘  │
└──────────────────────────────────────┘

This window can be described by the following tree:

               parentWindow
                   |
                 window
               /   |   \
              /    |    \
       win_l  winCount   win_r
      /    |     |          |-> incrementButton -> onClick increment
     /     |   count
    |    blank
   botLeftTriWindow
  /     |          \
"also" "empty :3"   \
                     \
                    winButtonHolder
                       |
                      decrementButton -> onClick decrement

In this example, the count is shared by all of the children of window (and all of its children too). When clicking the buttons, the count would be incremented or decremented, despite being nested so deeply in a child window. But parentWindow may not care about the state window holds. And what if winCount counted some other value alongside count that neither win_l nor win_r needed to manage? What type would these windows have? How should the events of the children be routed in a clean and comprehensible (not to mention extensible and modifiable) manner?

Once these issues related to the structure of the core systems are ironed out, a minimal working implementation could be written and features could be added from there (which all sounds like a lot of fun!).

I think Yampa has the capability to create an excellent interactive GUI system. yampa-gloss provides a great base to build this library off of.

[ivanperez-keera]

It would be really cool to make this happen. Now, implementing a full GUI library is a big undertaking! There are some prior work that I think would be important to take into account. Some of it may offer insights of where pitfalls and opportunities may lie. Other may present tradeoffs:

• Antony Courtney developed Fruit: https://www.antonycourtney.com/pubs/ac-thesis.pdf, https://gist.github.com/antonycourtney/4d10dfd2bdc953d7726c93f25542a527.
• I have long believed that Fudgets could be implemented completely on top of dunai (a Fudget is just an MSF with a side effect in the GUI): https://www.altocumulus.org/Fudgets/dist.html
• There's also the related Gadgets by Noble: https://pure.york.ac.uk/portal/en/publications/gadgets-lazy-functional-components-for-graphical-user-interfaces-2
• Finally, there are traditional GUI libraries. I wonder if it might make sense, and be possible, to design this new yampa-gui such that it could have backends that leverage existing UI libraries like GTK+, Qt, wx, and other native UI APIs.

[ivanperez-keera]

I'm turning this into a discussion for now. I think it's a better place to explore and propose ideas. Once we have a more concrete plan, we can create the issue or issues that will address the proposed change.