5 ms·
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.
by 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 agoSomething 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 agoThe 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 agoIs 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 agoVersus 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 agoNot 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.