Add a placeholder Rectangle into a layout whenever the last eleemnt is removed.
This makes sure we can drop into the Layout again.
Add infrastructure to find the parent element to ElementRcNode and move more
code into the ElementRcNode.
Updated the version from 1.1 to 1.2
Renamed the header to "Slint Royalty-free Desktop, Mobile, and Web Applications License"
Added definition of "Mobile Application" and grant of right
Moved "Limitations" to 3rd section and "License Conditions - Attributions" to 2nd section
Added flexibility to choose between showing "MadeWithSlint" as a dialog/splash screen or on a public webpage
Moved the para on copyright notices to section under "Limitations"
... so we can have a better idea what we need to visualize.
Move the decision on which color to use into the slint file as well:
A designer should make that call, not a developer ;-)
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;-)
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.
... 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.
Removes some duplication and lends itself for resue in the previewer :-)
Side-effect: We now consitently use versioned text documents, so the
editor will notice when the LSP refactored outdated data.
... 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
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.
Add helper functions into a new `element_catalog` module that extract
information on components used in a piece of Slint code on the LSP side
of the LSP.
Eventually this information will be passed on to the Preview side and
can then be used there to show available components.
- 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
The Preview delays starting the event loop as much as possible, simply
because our backends may panic/crash when they are not happy with the
UI configuration state they get started in.
So keep this... but use the `sender` in the Cache as an indicator of "we
have a UI". So explicitly set/reset the sender as the UI comes and goes
and do less implicit setup otherwise.
