The interpreter now creates the window typically in show(), so similar
to commit a8fcb5acd6 make show() return a
promise and invoke show() from within the event loop.
Amends d98c6773e1
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.
I somehow ended up in a situation where the Slint LSP logs where open
and VSCode was logging data into that. While my cursor was in an editor
with a .slint file open, the onDidChangeTextDocument events emitted by
the slint log file triggered yet another attempt to queryProperties.
This patch makes sure to ignore events from documents not containing
slint or rust files.
Add a toggle command to the LS and use them in VSCode.
Keep the existing set_design_mode commands for Slintpad, as it is easier
for the state stored on the web site and in the WASM side to go out of
sync. This is not an issue in VS Code at this point.
That's because since Slint 1.0 we show the last exported component,
and the `_Preview` component wasn't exported.
(The equivalent in the native LSP is already exported)
* Add "slintpad" to cspell white list for all languages
* Mention online_editor to slintpad rename in CHANGELOG
* Move tools/online_editor into tools/slintpad
* Update github actions accordingly
Co-authored-by: Olivier Goffart <olivier@woboq.com>
Stop the LSP from reporting progress information on file loading. This
caused problems with VSCode: First it triggered popups in the UI and
secondly it caused problems for the LSP that was asked to process
requests while calling back into the client.
Adapt the online editor and the two VSCode plugins to work with the
updated code.
Note: I did leave in the progress reporting code that can be used to
handle progress initiated by the _client_ side. That is just
notifications which will not block the LSP in any way and we might need
to support that at some point.
I did remove the Middleware code from the client side though that acted
on the progress information.
- Make the browser extention preview work
- Enable the properties tab on rust files
- Only call `offset_to_position_mapper` if the token is valid,
otherwise we might get an error visible in the UI.
... this gets rid of the remaining timeout and should make the whole
thing a bit more reliable.
It refreshes on *all* "done" messages from the LSP for now. I think this
is acceptable as the LSP is taking less than 10ms each time with the
printer demo (WASM).
