... 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 process key events while the preview is in design mode and does
not show an error. So far the only key that actually does something
is the delete key, which deletes elements. Unfortunately we do not
know which text range is covered by the element we want to delete,
so we delete random chunks of text.
So disable that when we ran into an error.
This partially addresses #4872.
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.
- Use "Library" instead of "Assets" as title
- Don't scroll the title when scrolling through the controls/widgets
- Use a bigger font than the category separators
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.
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.
The hack to sets the preview area's width and height through the init callback was run _after_ rendering the component container and during evaluation
of the dirty tracker. The latter sets itself to dirty = false after evaluation, so it's never dirty despite
the width and height having changed.
As a workaround for 1.4.1, move the init callback hack to before render() is called.
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.
- 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
- 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
- Add a title and icon to the window
- remove dead code (Spinner)
- Make the text of error align to the left and word-wrap
- With a pointer mouse cursor so the user knows they are clickable
