Live/pub-sub/reactive capabilities (input & other events, widget reactions, layout reactions)

[dumblob]

How would kui solve the example described in vlang/ui#7 (comment) and clarification?

There is no established terminology for this AFAIK, 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.

[kettle11]

I've been thinking lately about how a UI framework might pair with an ECS (Entity component system). If an ECS had a general purpose editor (so you could move components around between entities) then such an interface could also be used to rearrange the UI hierarchies if they were part of the ECS.

This would allow editing the UI by moving components in a tree hierarchy, but not by directly clicking and dragging the UI itself. Such an approach would be involve a substantial rework of kui so it's a ways out.

I appreciate your description here because it's challenging me to think of how to make it possible. I'll think on this and come back to it eventually.

[dumblob]

This would allow editing the UI by moving components in a tree hierarchy, but not by directly clicking and dragging the UI itself. Such an approach would be involve a substantial rework of kui so it's a ways out.

Hm, if I understand you correctly another disadvantage would probably be, that the number of widget instances would be fixed in compile time and couldn't be changed in runtime by spawning new instances and removing existing instances (both as reaction to some events as mentioned above 😉).

I appreciate your description here because it's challenging me to think of how to make it possible. I'll think on this and come back to it eventually.

Feel free to discuss it here - I'm curious what you'll come up with. I can only recommend reading all the linked sources (preferably recursively 😉) from the vlang/ui#7 thread. It might give you some hints how others approached this need (including "deliberately ignoring it" 😢 - which I think is not a good decision for any library aiming at supporting animations and advanced user interaction).