Hierarchical widgets – edit modes

[wdanilo]

Hi @farmaazon and @Frizi. I just had a short call with @farmaazon and I thought it would be good to share here some afterthoughts to be sure we are on the same page. In the list below, there is one idea that is a generalization of what we've been chatting about, so it's important to write it down.

Let's consider a code Cons 1 2 3. This is a constructor with 3 sliders. In such a case:

1. You can connect an edge to every widget. By default, this means that you can connect the edge to Cons, 1, 2, or 3. If you are holding cmd, you are also allowed to connect to Cons 1 and Cons 1 2, as these are way more rare cases.
2. Some widgets allow a safe, user friendly edit mode. For example, if you just click on a slider (don't drag it, just slick), it should show cursor and allow you editing its content. It should accept number input, but if you'd try to write "test" there, it will be rejected, as this is not a correct number literal. The same is about drop downs - if you click on a drop down, then not only list of things should appear, but also a search field. If you search in it and you write something that does not exist, it should be possible to force use what you've written. Anyway, this is the per-widget define edit mode and not every widget has to have it.
3. Every widget should have "edit as code" mode, after cmd - clicking it. So, in the case above, if I cmd-click the slider 1, I should see inline code-editor instead of slider 1. This would allow me to for example write a lambda expression as a slider value. Such a lambda expression should then be displayed as a function icon on the node, that you can edit by clicking, but this is just something "more advanced that we do not display by default". In such a case, editing the whole node is just a special case of that - if you cmd-click the self port (the root of the hierarchical widget), it should switch to the code edit mode.

[Frizi]

You can connect an edge to every widget.

I wonder if the connection logic should be somewhat modifyable per widget type. For example, widgets of custom shapes (e.g. join type) might have slightly different requirements around mouse handling. In that way, it would also be possible to create a widget that doesn't allow any connection, if we ever need that.

Some widgets allow a safe, user friendly edit mode.

The dropdown selection logic is just one such implementation of localized edit. I see no issues with allowing other input methods, which would use the same API for submitting changes.

Specifically for dropdowns, there is also a complication related to manual input. The entries are displayed in shortened or simplified form, the labels don't have to be valid code. For example, when selecting a column name, the dropdown shows unquoted names. When one is selected, the actual inserted expression ends up being a quoted string literal. Similar thing can happen for other non-string types. Custom entry via input field will have to be aware of correct reverse transformation to transform user input into valid expression.

Either way, those specifics are left up to the widget. The edit is performed by providing an expression for replacement at given span tree crumbs.

In such a case, editing the whole node is just a special case of that - if you cmd-click the self port (the root of the hierarchical widget), it should switch to the code edit mode.

I like the idea, though it makes #5919 somewhat obsolete. I will still continue with it, as it will be a good first step and will be useful during widget tree development. Eventually all that logic will be moved into the widget tree. In fact, if we would have an "code editor" widget, the edit mode can be implemented as a temporary switch to that widget type for given subtree. Navigating or selecting past start/end of that code could transform further widgets to the left or right into code editors as well.

Additionaly, that code editor widget could be integrated with component browser, using existing cursor-aware CB logic.