You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is no established terminology for this IIRC, so I call it live variables or it can be viewed as reliable pub-sub mechanism or as reactors or reactivity or as "streaming data API" etc. The point is to express with the lowest possible number of SLOC that two or more distinct widget instances (each of different kind of widget and in a completely different unrelated part of the app) should get the same input event instance (kbd, mouse, IPC, ... - e.g. significant layout change as linked above) and if the widget is not "read only" (e.g. label is read only, but a button with picture/label is both read & write), then the widget instance shall also at the same time have the capability to create any number of new event instances of any kind and anyone interested in this event (i.e. "subscribed") must guaranteed receive it. This everything with defaults so well handled that most common use cases (let's define this to be equivalent to 7GUIs) shall have the very minimum of SLOC (of Rust and YAML) possible.
The text was updated successfully, but these errors were encountered:
dumblob
changed the title
Live/pub-sub capabilities (input & other events, widget reactions, layout reactions)
Live/pub-sub/reactive capabilities (input & other events, widget reactions, layout reactions)
Sep 14, 2020
I actually think Thyme is fairly well positioned to support this (very complex) use case, the way the widget themes work already provide a significant fraction of what you are describing, although at present editing the layout means editing the YAML file, not drag and drop.
As a starting point, live reload (#2) needs to be fully implemented.
I admit, I didn't dive deep into the code, so this is a very pleasant finding. It'd be great to have it as a fully functional demo to showcase the capabilities of this library.
How would thyme solve the example described in vlang/ui#7 (comment) and clarification?
There is no established terminology for this IIRC, so I call it live variables or it can be viewed as reliable pub-sub mechanism or as reactors or reactivity or as "streaming data API" etc. The point is to express with the lowest possible number of SLOC that two or more distinct widget instances (each of different kind of widget and in a completely different unrelated part of the app) should get the same input event instance (kbd, mouse, IPC, ... - e.g. significant layout change as linked above) and if the widget is not "read only" (e.g. label is read only, but a button with picture/label is both read & write), then the widget instance shall also at the same time have the capability to create any number of new event instances of any kind and anyone interested in this event (i.e. "subscribed") must guaranteed receive it. This everything with defaults so well handled that most common use cases (let's define this to be equivalent to 7GUIs) shall have the very minimum of SLOC (of Rust and YAML) possible.
The text was updated successfully, but these errors were encountered: