4 ms·

We're still figuring this out, a discussion on the #crochet stream in our Zulip today is on this very topic. At a very high level though, many events (mouse mov

We're still figuring this out, a discussion on the #crochet stream in our Zulip today is on this very topic. At a very high level though, many events (mouse movement, keyboard, etc) are handled by widgets, not by app logic, and those are dispatched to the widget by the toolkit calling into the widget Trait's `event` method. The idea that a button is clicked is different, we tend to call that an "action" rather than an event. In current Druid, it's a callback which is given access to mutable app state (often through a lens). In Crochet, it's placed in an "action queue" and the app logic is rerun when the queue is nonempty, then everything is rendered after the app logic has had a chance to make its mutations to the view tree. We don't have the one frame latency, as it's not imgui under the hood. (There's a bug in the Crochet prototype on this, but it's known and will be fixed). Hope this helps clear things up a bit.

liuliu 6y ago
What about drag gesture? I.e. if you want to enable a particular widgets such as image display / text box to be draggable? How the event should be passed in and handled? These gestures seems not internal to the widgets, but also mutate the widgets state in one way or another and need some abstraction to handle the common behavior.
- raphlinus 6y ago
  That is indeed a complicated case we haven't fully figured out yet. We've started thinking about it, but don't yet have an implementation.
  - c-smile 6y ago
    Something tells me that you will end up in HTML/CSS/DOM and bubbling/sinking event propagation schema (used in browsers) as the most flexible one, see: https://en.wikipedia.org/wiki/Event_bubbling https://en.wikipedia.org/wiki/Event_bubbling I did quite a lot of different attempts to GUI Holy Grail in last 20 years ( https://sciter.com/10-years-road-to-sciter/ https://sciter.com/10-years-road-to-sciter/ ) . I am pretty confident that DOM and DOM events is the most flexible (and so robust) foundation so far.
    - pjmlp 6y ago
      The problem is that to make it flexible in a way that allows for GUI construction blocks, with Rust one would end up with Rc<RefCell<>> everywhere, like it happens in Gtk-rs.
      - Groxx 6y ago
        Is that all that bad of a thing? You could combine them into a single type, which then becomes a type marker for "is / related to a UI element" and perhaps more palatable to type.
        pjmlp 6y ago
        Versus what languages with proper GC support? Plenty, decrease in productivity, basically back to Objective-C before GC/ARC, or doing COM in C, lack of support in GUI designers that need to always map to the same types, and building on top of that a big attrition for component libraries.
        Groxx 6y ago
        Not sure if I'm missing something, but how does Rc<RefCell<...>> equate to "objective-c before gc/arc"? It seems roughly equivalent, in the same way that smart pointers are roughly equivalent: the lifetime is inferred by use, and retaining cycles are a problem. Arc could be a little bit more efficient (which does matter in some ui work), but I don't see how it'd change the use of a framework, and iOS and OSX devs have used objc with arc for years successfully and often happily.

liuliu 6y ago

What about drag gesture? I.e. if you want to enable a particular widgets such as image display / text box to be draggable? How the event should be passed in and handled? These gestures seems not internal to the widgets, but also mutate the widgets state in one way or another and need some abstraction to handle the common behavior.

raphlinus 6y ago
That is indeed a complicated case we haven't fully figured out yet. We've started thinking about it, but don't yet have an implementation.
- c-smile 6y ago
  Something tells me that you will end up in HTML/CSS/DOM and bubbling/sinking event propagation schema (used in browsers) as the most flexible one, see: https://en.wikipedia.org/wiki/Event_bubbling https://en.wikipedia.org/wiki/Event_bubbling I did quite a lot of different attempts to GUI Holy Grail in last 20 years ( https://sciter.com/10-years-road-to-sciter/ https://sciter.com/10-years-road-to-sciter/ ) . I am pretty confident that DOM and DOM events is the most flexible (and so robust) foundation so far.
  - pjmlp 6y ago
    The problem is that to make it flexible in a way that allows for GUI construction blocks, with Rust one would end up with Rc<RefCell<>> everywhere, like it happens in Gtk-rs.
    - Groxx 6y ago
      Is that all that bad of a thing? You could combine them into a single type, which then becomes a type marker for "is / related to a UI element" and perhaps more palatable to type.
      - pjmlp 6y ago
        Versus what languages with proper GC support? Plenty, decrease in productivity, basically back to Objective-C before GC/ARC, or doing COM in C, lack of support in GUI designers that need to always map to the same types, and building on top of that a big attrition for component libraries.
        Groxx 6y ago
        Not sure if I'm missing something, but how does Rc<RefCell<...>> equate to "objective-c before gc/arc"? It seems roughly equivalent, in the same way that smart pointers are roughly equivalent: the lifetime is inferred by use, and retaining cycles are a problem. Arc could be a little bit more efficient (which does matter in some ui work), but I don't see how it'd change the use of a framework, and iOS and OSX devs have used objc with arc for years successfully and often happily.