After commit 7df902b53c, the winit window
is not created when calling show() anymore but it's now created at
component creation time. That means the event loop workaround removed
in 459f810bd8 is now needed at
construction time.
Since this is a winit and wasm specific issue, it's now dealt with in
the wasm interpreter implementation, by invoking the creation from the
event loop from there and returning a promise in the API.
This changes the API therefore: create() can only be called after the
event loop is running.
* compiler: Make mapping from source offset to line/column more reusable
* compiler: Improve mapping of offset to line/column
* Fix unit tests after line mapping update
* interpreter: Add code to have a element picker mode
* slintpad: Add picker mode to the preview
* slintpad: Do not try to highlight "empty" highlight requests
* Slintpad: Cycle through all the possible elements in design mode
* Slintpad: Ignore builtins and eat less clicks
* Slintpad: Highlight the element selected in design mode
* Slintpad: Do not use static mut variable in design mode
* slintpad: Rename `set_current_element_information_callback`
* Interpreter: Do not use unsafe in design mode code
Done with: @ogoffart and @tronical
crates.io won't let us upload a feature with dots in it:
```
Uploading slint-interpreter v0.3.0 (/home/olivier/slint/internal/interpreter)
error: failed to publish to registry at https://crates.io
Caused by:
the remote server responded with an error: invalid upload request: invalid value: string "compat-0.3.0", expected a valid feature name at line 1 column 2254
```
There's a memory leak that causes the created canvas elements not be
deleted. I've tried a few thing such as explicitly hiding the window
(destroying the canvas element instance refs and gl resources we keep in
Rust), but it's not enough - somewhere there remains a circular
reference. Possibly between some of the closures installed in Rust and
DOM elements they are installed on as event handlers.
I also tried using the wasm-bindgen support for weak refs, but no luck.
So instead, to plug the leak, this patch introduces the re-use of the
HTML canvas element in a way that is similar to how the preview works in
vs code's live preview.
I verified that no GL resources or new canvas elements are leaked in
Chrome's heap profiler via snapshot comparison and filtering for the
corresponding DOM element types.
We don't need to compile cpp, qttypes, and all such dependencies to only
have the qt backend's buildscript ignore the qt compilation error and
fallback to the dummy no_qt backend.
Only the last shown preview was interactive. This was because we started the winit event loop for each preview,
which kind of invalidates the previous instance in winit.
Instead, create all components, call show() on each instance to register the window with winit
and spin the event loop with its exception magic only once.
