Only the hand-picked sensible things, not all of it ;-)
Also fix a few typos that cspell complained about when I
tried to commit and some formatting changes that cargo fmt
insisted on when commiting.
Add `fills_aprent` and `default_properties` to
`ComponentInformation`. The first is a bool showing
whether the Component will fill its parent or not.
The later is a set of properties that the UI will set
when the widget gets dropped.
Refactor the data passing a bit: Keep the data on known
components around. Pass only the component name into
the UI, but pass the entire `ComponentInformation` to
the `drop_location` methods.
Slpit up `lookup_type_for_child_elemnt` (in the compiler) into the
part that looks at the element itself only (called `accepts_child_element`)
and the part that looks at the child.
When deciding whether we can drop something into another element in
the live preview, we know the child type is going to be OK, even when
the `TypeRegister` does not contain it yet (as it is not imported yet).
We recently got better support for inlined elements. Use
The `ElementRcNode` when accessing properties, so that
we can actually have a better idea which SyntaxNode we
need to work on.
This is actually not too critical as the LSP does little
inlining, but I wanted to reuse this on the preview side
as well, which does inlining much more aggressively.
Do NOT access properties in the live preview though:
It is heavily optiomized, so most properties are just
gone there;-)
Allow moving and resizing of elements provided:
* The element is not layout. This approximates
"fills its parent", which is what we aim for once
we can query type info rom within the Preview.
* The element is not *inside* a layout
Changing the size of a UI will most likely move elements
around. So reselect the current selection when that happens.
This is not a proper solution: It e.g. ignores animations
changing element sizes, etc. but it does handle one
annoying case.
Have the LS notify the live preview about changes it initiates, so
the live preview can update its selection.
This is not possible for all edits the LS generates: Many are sent
to the editor which may or may not trigger them later, but the
notification happens when the LS adds changes on top of changes
requested by the live preview (e.g. by adding an import). This
fixes having a newly added element selected once it is rendered.
We need to decorate an Element so we can interact with it. I want
to decorate only *one* instance of a repeated element to avoid
cluttering up the screen. So pick one good candidate for decoration:
Ideally the one the user clicked on, got for the first one
otherwise.
Store this information so we can get it back after re-rendering,
and so that we can actually mark newly added elements for selection
after they get rendered.
... in native mode,
Have the channel between the two transport
`PreviewToLspMessages` directly instead of wrapping
those into `Notifications` of the language server
protocol.
Unformtunately the notification code eneds to stay in
place, as that is what the WASM preview uses to talk
to a native LSP.
I did nto unify wasm and native handling of the
`PreviewToLspMessage`s: The different async runtimes
we need to integrate with got into the way.
... and make it show up in the code/live preview.
Currently layouts are not supported and it will try to drop
onto elements not accepting children.
But it does add the necessary import statement already.
Move the code that sends to the editor from within the LSP and the live
preview into a module in common.
This makes it clearer what actually happens and allows to remove some
code from the preview that does not really belong there.
... and use it e.g. for the nodes the preview adds into the code itself.
Now that we mark the preview helper we add into the file as `ignore`, we
can make sure we never try to navigate to it. It was text that got
appended to the actual source code, so the editor tended to jump to the
end of the document when selecting the root element. That was created by
merging the artifical Preview node and the real root node, with the
artificial node being stored first.
The messages serialized through the LSP should use the LSP's url type.
And keep type information as long as possible.
Otherwise, we'd end up in show_document_request_from_element_callback
with either an URL or a path, depending if the preview is native or not,
and that would fail when re-serializing to an URL to send back to
through the LSP
This is a long odyssee :-/
I am back to file-based navigation now: The component-based navigation
felt so very tree-based again.
So you can click anywhere to select the "topmost" rendered element that
is defined in the same file that is getting previewed.
A double-click is again punching through the layers: It goes deeper into
the rendering layers, selecting an item at the same point but covered by
the current selection.
Ctrl makes the selection ignore file boundaries when picking something.
Shift reverses the search direction when double clicking: It will pick
an element in the click position that is rendered after the currently
selected item.
Try a more visual selection approach over the rather technical
tree-based one from earlier.
In this commit, a click selects the element that was rendered at the
click position *last*. I use rendered loosely here: It even takes
elements into account that are invisible but still cover the clicked
location.
A double-click punshes through to the item rendered earlier (behind) the
currently selected item that also covers the clicked position.
A shift-double-click moves towards the later rendered elements again,
usually undoing the last double-click.
It is tree based now: Allowing you to visit children, the siblings and
the parent of the current selection.
Advantage: You can actually get to all elements now, even those covered by
other elements.
Disadvantage: You basically need the document outline to make sense of
the navigation:-/
We need a more visual way to select elements! But how can we even tell
which elements are going to be visible in the UI and which are not?
Here is how you navigate in this PR:
* Click selects an element. If the click hits the currently selected
element, then it will do nothing. Otherwise it will look whether a
sibling was hit, working its way up the tree to the root element.
* Double-click selects a child of the current selection: the "foremost"
child that covers the click location will be selected.
* shift-double-click: Takes you to the current selections parent.
* Ctrl-click: Select a sibling of the current selected element "behind"
the sibling that covers the current click location.
* Shift-ctrl-click: Selects a sibling of the current selected element
in front of the current selection that cover s the click location.
We want the previewer to become interactive, so we need to pass on the
document versions so we can detect the editor, lsp and previewer going
out of sync.
- make sure that the initial size is proper by calling show() on the preview ui
after the factory has been set
- ensure that there is no recursion if the inner layout info depends on the size
(Fixes#3989)
- Ensure that the geometry constraints are respected when previewing a component
that was already resized
The compiler automatically adds a Window on top of the actual root
element when that isn't a Window already. When selecting the added
window element would get ignored and the "real" root element would get
selected as its only child. That causes the cursor to jump to the end of
the document.
So skip auto-added Windows when selecting, starting with the "real" root
element.
- Put the config in a struct so its easier to pass around
- respect the command line args as default for the style
- fix compilation without the preview feature
