yes, fair enough regarding the multiple frontends. having a one-size-fits-all approach to UI development always leads to tradeoffs and you may get more of them once you try to support multiple paradigms. having said that, tools like QML are handling embedded, mobile and desktop use-cases and they’re fairly successful in that regard.
doesn’t mean you need to design all of them upfront, certainly.
re state management: for me this has always the main pain point when using UI libraries. for instance, if you want to have a custom TreeView in Qt you need to do a custom implementation of QAbstractTreeModel and you’re basically asked to implement methods like “give me the Nth child of this specific item”, “what’s the tooltip of this item”, “what is the parent of this item”. additionally you need to emit the right messages at the right time, so that all UI components understand when an item has been inserted in a specific position. this is surprisingly tricky to get right, and Qt even ships a “ModelTester” class that you can use to unit test your custom model. I wrote a custom TreeModel at one point that worked in a “React”-style approach using diffs between previous and current state, and would emit the appropriate events based on that, but this was of course relatively slow for large trees.
so for a good state management crate you’d probably have to start with persistent data structures (like trees), that understand the concept of “previous state” and “current state”.
if you have that working, undo/redo also flows naturally from that, without having to write tons of custom undo/redo command implementations.
btw, I just saw this on Hacker News. It's a gallery of lots of different kinds of UIs: https://docs.google.com/presentation/d/1MD-CgzODFWzdpnYXr8bEgysfDmb8PDV6iCAjH5JIvaI/preview#slide=id.g1da0625f1b_0_56
that'll just lead to the same problem as qt's abstract models, but instead of herding events you're just herding mutations
one thing I've been considering is something like QAbstractTreeModel but where it doesn't use events to update the UI
and instead it just unconditionally repaints everything visible whenever anything has changed
which gives a react/vue-like flow but without any diffing
the event loop might look something like this:
- receive OS event(s)
- run capture+bubble triggering based on cursor and focus, filtering OS events to more semantic events (but not changing any state)
- pass the semantic events off to "components" and actually update state in response (this includes both UI state like scrolling/text selection/etc and user state like text/radio selection/etc)
- re-run styling, layout, and paint, then go back to waiting on OS events
with that default probably-doing-too-much flow you could imagine compartmentalizing things in step 3 so that you know which sub-sections of the UI need layout/etc
but that could be approached as an optimization, rather than something the user has to get right or risk dropping stuff on the floor
but scene graphs often include the actual data as well
@madmalik Yeah, sorry, haven't been around. The "software" was Progress 4GL RAD Development. It's a fairly sophisticated 4GL database language that's been around since the '80's that ran on everything from DOS up to large Unix boxes and Mainframes. It was kind of ahead of its time. It's still around, but, Open Source, Java, C#, etc have really cut into its market.
for those of you that are still interested in this topic http://areweguiyet.com/newsfeed/2018-01-13_rust2019.html
And if we already have it, what are type of sync and concurrency it use? Actor model or maybe it now providing it part
