Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
    Roy Jacobs
    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
    Russell Johnston
    I'd rather not tie anyone to a specific data structure either
    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
    Russell Johnston
    the event loop might look something like this:
    1. receive OS event(s)
    2. run capture+bubble triggering based on cursor and focus, filtering OS events to more semantic events (but not changing any state)
    3. 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)
    4. 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
    Russell Johnston
    the key API data structure there, I think, would be a kind of "template" that looks a lot like the DOM but doesn't contain any content, only handles into the state which could then be stored any way the user likes
    @rpjohnst like a scene graph in a video game?
    Russell Johnston
    definitely related
    but scene graphs often include the actual data as well
    i was thinking more of how its done with entity component system thingies
    Russell Johnston
    the rendering approach is basically the same
    yeah, modern game architecture should be pretty applicable to GUIs, at least partly
    Gerald E Butler
    @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.
    @gbutler69 thanks!
    Connor Brewster
    Is this WG still active?
    Dustin Bensing
    for those of you that are still interested in this topic http://areweguiyet.com/newsfeed/2018-01-13_rust2019.html
    Dmitry Opokin
    Have we now ecs gui with trait based logic representation?
    And if we already have it, what are type of sync and concurrency it use? Actor model or maybe it now providing it part
    Michael Kruglos
    Are there any commercial rust gui applications? What do they use for gui?