Make the extension set SLINT_LSP_PANIC_LOG_DIR (instead of setting a file).
Have the Lsp/live preview create panic logs in that folder as panics happen.
Make the extension watch that folder and upload any file it sees getting created there
Delete the file after upload
Start the live preview in a separate process. This simplifies
a couple of things:
* Starting the UI
* UI state handling
* Threading setup
* "Quitting" the preview on Mac
... and many more :-)
With jemalloc the page size is a compile time constant that results in
the process aborting on memory allocation if the compile time determined
page size does not match the kernel reported page size at run-time.
When we, or our users, compile the above programs for aarch64-linux,
there is a fair expectation that the resulting binary works on any
aarch64-linux system. As we can't determine the target page size
reliably, disable jemalloc.
Fixes#8134
* optimize: use jemalloc for slint-viewer
The lots of allocations are slowing down slint-viewer.
By using the faster jemalloc, we get a significant time boost
on Linux at least, where I can observe a 15% time reduction:
Before:
```
Time (mean ± σ): 936.6 ms ± 13.5 ms [User: 688.8 ms, System: 191.1 ms]
Range (min … max): 918.9 ms … 955.6 ms 10 runs
```
After:
```
Time (mean ± σ): 794.8 ms ± 16.2 ms [User: 645.4 ms, System: 99.2 ms]
Range (min … max): 755.0 ms … 810.7 ms 10 runs
```
* optimize: also use jemalloc for slint-compiler
As with the slint-viewer, we can observe a drastic time improvement
of around 13% when using jemalloc for slint-compiler:
Before:
```
Time (mean ± σ): 772.8 ms ± 9.2 ms [User: 633.5 ms, System: 136.5 ms]
Range (min … max): 763.3 ms … 787.8 ms 10 runs
```
After:
```
Time (mean ± σ): 672.5 ms ± 13.5 ms [User: 610.4 ms, System: 60.1 ms]
Range (min … max): 655.1 ms … 700.7 ms 10 runs
```
* optimize: also use jemalloc for slint-lsp
The impact here was not measured, but it should be in a similar
ballpark to the slint-compiler and slint-viewer, and thus quite
noticeable in practice.
The change in https://github.com/slint-ui/slint/pull/6747
invalidated the cache, but it was only reloaded when one of the dependent was reloaded.
We need to reload the cache for all open file so that LSP feature continue to work on
open document even if they get no changes
... and ignore them on file change notifications: The
Editor manages the file content, so we do not need to
care for the on-disk content for these files.
Get a notification of any file change/deleteion. This feels like
overdoing it a bit, but we need to reload when resources change
and those can be anything.
We need to do the platform init only when we intend to soon thereafter show a window.
Re-added a Quit item that merely hides the UI, so CMD+Q kind of works for convenience.
Fixes#5994
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"
We created a `ServerNotifier`, cloned that and passed one copy
on to the `CompilerConfiguration` so that imports would notify the
preview.
Unfortunately that does not work: That clone never gets told to
switch over to the WASM preview and will always try to update the native
preview instead.
So make sure the information which preview is used gets
synchrnoized to all clones using an atomic bool and an Arc...
Fixes: #4764
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;-)
... in native mode,
Have the channel between the two transport
`PreviewToLspMessages` directly instead of wrapping
those into `Notifications` of the language server
protocol.
Unformtunately the notification code eneds to stay in
place, as that is what the WASM preview uses to talk
to a native LSP.
I did nto unify wasm and native handling of the
`PreviewToLspMessage`s: The different async runtimes
we need to integrate with got into the way.
