Widgets integrated with graph nodes

[Frizi]

Pull Request Description

Rewrites node input component. Now the input is composed of multiple widget components arranged in a tree of views with automatic layout. That allows creating complex UI elements on top of the node itself, and further widget positions will be automatically adapted to that. The tree roughly follow the span tree, as it is built by consuming its nodes and eagerly creating widgets from them. The tree is rebuilt every time the expression changes, but that rebuild process reuses as much previously created widgets as possible, and only updates their configuration as needed. Each widget type can have its own configuration options that can be passed to it from the parent, or assigned based on configuration received from the language server.

Important Notes

For now, all span-tree updates are sent over to the shared Frp endpoint of the whole tree, so there is no mechanism for intercepting them by the parent widgets. One idea would be to use existing bubbling/capturing events on widget display objects for that purpose, but I think existing implementation is simpler and more convenient, and we can always easily change that if we have a use for it.

There are some issues with performance due to much more display objects being created on the graph. Expect it to be a little worse, especially at initialization time.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

[wdanilo]

call note: to be probably deleted as, current_offset probably should be offset to sibling.

[Frizi]

I found that there is a good reason for storing offset to parent. The child method allows random access to any child by index, and it requires parent offset to easily calculate the child span's start. It is used everywhere, as it is the base of indexing the tree by crumbs. So we have to it. I will rename the fields and fix some inaccurate comments to make it a little better.

[Frizi]

Found regressions:

• when creating new node, the node background is invisible until the user starts typing
• when creating new node by dragging an edge, the connected edge is not aligned properly to the node center
• when dragging an edge grabbed on target side, the cursor style is not updated

[vitvakatu]

QA Report 🟢

I didn't spot any serious issues.

1. Ridiculous issue I spotted when mindlessly moving connections.

2023-04-26.15-39-15.mp4

2. Ctrl-clicking on nodes usually places the mouse cursor in a completely random place, I didn't spot any pattern there. It can go to the beginning of the code, to the end, a few characters to the side, or exactly to the place you clicked.
3. Sometimes, it's impossible to connect to the specific element of the array. Simpler cases work fine, though.

2023-04-26.15-27-58.mp4

[MichaelMauderer]

QA Report 🟢

No issue spotted that originated in this PR. #6221 still seems to be present.