How are these other state concerns you mention (e.g., focus) handles in immediate mode GUIs? Do the components retain those states or do you keep a separate model for those states that needs to interact with the application model? If so, how is that interaction wired up?
I would argue that the state of the global model includes some information about the state of a widget (e.g. selected="true") and some state is unique to the widget itself (hover).
The trick here is how do you reconcile those two states when both have a copy of the data. For instance, the <input type="text" /> holds its own state and you hold the value in the global state. When a user types a character into the input, the input hold a copy of the letter in its "value", and the state is updated with the same value, which then triggers the input to compare its state with that of the global state for equality before attempting to render the value in the global state. Tricky stuff.
If I understand correctly, the distinction between immediate mode GUI and retained is that in the former, there aren’t stateful widgets so there is no copy to reconcile.
That's correct. State is handled by the user, which is great for some things(dynamic quantities of elements - no caching layers, just feed it a for loop) and awful for others(maintaining pre-committed state for e.g. a configuration panel with checkboxes, text fields, etc.)
Ultimately the ground truth in both instances is that you have potentially many data models that the UI has to aggregate, and the source model, layout, display properties and hitboxes of elements are usually but not totally related and can change due to many kinds of events. Any formal structure you might come up with is bound to run into exceptions. As a result I tend to have this policy:
* I don't trust the framework
* But I leverage the framework to produce early results, and both immediate and retained modes offer ways of doing that
* I expect long-term maintenance to involve a customized framework design regardless
