If a `slint.json` file is found, that one is parsed for extra
information like what is the main file and what extra mappings exists
(e.g. so you can redirect to images, etc. in different repositories).
We have a lot of fun with the URLs/file names we use:
* We need to map URLs (e.g. to store them in Gists), so we can not just use
the external URLs everywhere :-(
* We need some way to tell "internal" URLs from external ones
* We want "https" as that works best in a browser: "file" tends to
fail to load for security reasons, "inmemory" is no proper scheme.
* LSP/Previewer and Editor disagree on the "inmemory" scheme, which has
caused me headaches before.
So use https URLs with an authority of "<UUID>.slint.rs" and treat them
as internal URLs.
Wait for the service worker to come up fully. The API is a bit unwieldy,
but we tell to not wait and to claim all clients, so it should come up
the first time round.
This service worker can be used to report and remap access to resources
from the previewer. We will need this feature to be able to meaningfully
export data.
This is not used yet!
Do not raise an alert for URLs the LSP/previewer requested. This prevents breaking the flow as the user types an import statement which the LSP/previewer then can not find.
Continue to alert about problems with URLs explicitly opened by the user. This is important so that we do not silently fail when trying to open a file from an URL.
Fixes: #2377
... and remove package-lock.json again.
This is what I saw Theia doing, and it does not hard-code the world,
just those parts we actually need to have hard-coded.
Unfortunately this is not as useful as I had hoped: Download from pretty
much every git hoster fails due to CORS. The big exception is
github.com, which has raw.githubusercontent.com to work around this
problem.
I added automatic conversion to raw links (which allow CORS!) from
"normal" links to make this easier to use. Gists work, too, provided you
paste the link you get when clicking on "Raw" for the specific file of
the gist you want to view.
The current latest versions of all our dependencies do not play well
together.
Monaco-languageclient claims to support monaco-editor 0.34.1 only, so
let's stick to that. We also need to make sure everybody agrees on using
the same vscode-jsonrpc version (which was recently updated in the
vscode dependencies), or the typescript code will fail to communicate
with our language server.
So include the package-lock.json for now, so that we can actually build
something.
Spaces are no longer inserted around the cursor when user autocompletes
a component or a callback handler.
These spaces result in a spurious whitespace and misaligned curly braces
right after the user presses enter. Since most components and callback
handlers are multi-line, this often requires additional keystrokes to
fix.
The problem is present even in Slint's own examples. Such as
examples/gallery/ui/side_bar.slint - line 127
Firefox does not handle modules in web workers yet, but that is what we
asked vite to build (to work around a compatibility issue after
upgrading to vite 4). So Chrome worked, but Firefox did not.
This PR adds a pretty ugly work around to that problem.
The good news is: Firefox will apparently be able to handle modules in
web workers starting with 111, so let's hope we do not need this for too
long!
We already detected that `slint!` in a comment should not be interpreted
as a slint macro, but that detection failed for `slint::slint!` or if
`slint` was twice in the same line.
The update to vite 4 triggered the vite 3 bug vitejs/vite#9879
for us, where the wasm-pack generated .js is included as iife and
therefore the use of import.meta.url gets transpiled to some shim that
tries to access the document, assuming that the JS is running in the
browser instead of in a worker environment.
Explicitly set the output type for the worker to ES modules, so that no
changes are needed and import.meta.url remains in use. This matches the
worker invocation anyway, as we pass "type": "module" to the Worker
constructor.
The upgrade of vite from 2 to 4 in commit
5951ae6272 also brought an update of
rollup to version three. That one documents that relative externals are
resolved to absolute paths by default, which explains the symptom that
the online editor tried to load /some/absolute/path/wasm_interpreter.js.
Resolving back to resolve paths fixes it.
The code used to sometimes throw a strange exception indicating that the
previewer WASM module was not fully up yet when used.
Fix the LspWaiter to really wait for both LSP WASM web worker and WASM
previewer to report back that they are fully up. Previously it only
waited for the Lsp, which surprisingly often works on my machine.
Basically same as e88b07997f but in the
set_binding_command function.
(made the code more similar to remove_binding_command, I think the two
function should be merged in the future)
This fix editing binding within the root component when it inherits from
something.
When removing a property binding, the editor notified the Properties
Widget before the LSP was updated. So the LSP continued to provide the
old data on the Property Widgets request. So the removed property
binding was still shown as set.
Work around this by polling the LSP till it returns a source version we
expect (or something newer). This should be save enough I hope.
This sets up the file reader, which has gone missing in action at some
point.
We used to open the main file of the printer demo. That trriggered
loading of all the helper files, but they all came back empty. So any
LSP request that came in got errors as the code was incomplete.
Afterwards the editor loads the files anyway, telling the LSP about the
loaded file each time, filling in the missing information. So after all
files are open in the editor, the information in the LSP is complete and
all LSP commands return proper information going forward.
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.
Currently, the reported range is the range of the root element, which
doesn't include the name of the component itself.
While the Name of the component itself is used as the selection range.
Vscode assrts that the selection range is within the range:
```
ERR selectionRange must be contained in fullRange: Error: selectionRange must be contained in fullRange
```
So use the full component range for the range instead
This type is poorly implemented and not documented. Let's remove it for now.
It shall remain available in the git history in the event of a resurrection.
