LivelyKernel / lively.next

lively.next is a personal programming kit. It emphasizes liveness, directness, and interactivity.
https://lively-next.org
MIT License
68 stars 16 forks source link

UI support for creation and inspection of Connections #163

Open rickmcgeer opened 3 years ago

rickmcgeer commented 3 years ago

I had a button which had a connection on fire to a method. The method wasn't firing, but when I invoked the method directly it worked fine. So I checked the connection on the Scene graph, and the connection appeared to be there -- to the right morph, and to the right method. Deleting the connection and making a new one fixed the problem. Just to check, I put a show() in the method being connected to. When I invoked the method directly, it worked fine. However, when I pushed the button, I got an error-in-interactive alert, and the message trail said, essentially, I can't find the object to show. So what seems clear is that the connection was to a dead object; the point is, the UI should make this obvious.

merryman commented 1 year ago

Since this came up quite recently again in #809, I want to briefly outline what is hard about building a good interface for managing connections:

A visual interface for managing connections needs to satisfy the following points:

  1. Should be direct and live: This is in accordance with the morphic paradigm. It means that we can initialize a connection from directly interacting with the visual elements it connects to in the world. It also means that as soon as the connection is created it is live. (think about hooking up a button to its editor and it being able to immediately trigger the behavior). Whats at odds here is that oftentimes (especially in deeply nested UIs) it is not so easy to precisely select the visual blocks to be connected. We have experimented with different approaches to fix this problems (prompting context menus, scene graph selection) with varying degrees of success. I can outline these past solutions in more detail if requested.
  2. It should reduce the friction in setting up connections: By that I mean that the system should convey what can be connected to and ideally what can be connected to wich. This is tricky from a technical perspective since we have neither a typesystem nor a powerful inference system in lively.next such as intellisense. Maybe LLMs can give us a big bang for the buck, but that feels like a couple of experimental weeks we need to set aside to figure that out.
  3. It should provide for a structural overview of how events and signals flow. Oftentimes this is the question of how the handlers get to trigger a specific behavior. We need to know this if we want to A.) fix a bug or B.) implement new behavior in the "correct manner". In the past I have always found this aspect of the UI to be quite a odds with 1.) Since a direct and live interface oftentimes does not scale well for large interconnected systems with loads of connections and handlers installed.