Set up the underlying graphics API with WGPU, render into the queue with
skia, present with WGPU. Opens path to importing wgpu textures, provided
that we synchronize them (i.e. pipeline barriers/transitions if needed).
For the implementation of BuiltinFunction::GetWindowDefaultFontSize, instead of going to the window adapter's window item rc (which will be the outermost window item), start at the first item of the current component and work the way up from there.
Fixes#4298
After commit e04f028c91, the
default-font-size property on WindowItem isn't set anymore by default,
so BuiltinFunction::GetWindowDefaultFontSize, which reads it, would
return zero.
Instead, delegate to a run-time function where we can fall back to the
default from the renderer.
This patch changes rem.slint to use the newer syntax. The main change to
the test case though is to removal of the explicit default-font-size
property setting, so that we fall back to the value provided by the
renderer. This test relies on being run with the testing backend.
Fixes#8961
Quoting from the BufWriter docs:
>It is critical to call flush before BufWriter<W> is dropped. Though
>dropping will attempt to flush the contents of the buffer, any errors
>that happen in the process of dropping will be ignored. Calling flush
>ensures that the buffer is empty and thus dropping will not even
>attempt file operations.
The second constructor of `Slice` causes the Slice to be passed
differently (in different register) as a return value.
So remove that constructor and use a helper function to
construct a Slice
Previously there were two kinds of Menu:
1. "Simple" menu that don't have any `if` or `for`
2. "Complex" menu that have `if` and `for`
For the first kind, we were generating in the compiler the `entries` and
`sub-menu` callback. This lead to more efficient and simple code at
runtime.
For the second kind, we generate an item tree so we can dynamically
produce them at runtime.
The issue is that as we added feature, the code became complex to
handle, even in the simple case as we need to create a `VRc<MenuVTable>`
also for the context menu so we can have native context menu.
We still need the "Simple" case for the internal though.
So for that I added a ShowPopupMenuInternal builtin function although it
only differ from ShowPopupMenu by the type of its second argument.
Since the generated code has lots in common, they are still handled
together.
The proof that the two different codepath were harmful is that removing
it showed a bug with contextmenu within repeated element.
the `contextmenu_delete.slint` started failling. It worked before
because it was only a problem with "Complex" menu and the test used a
"Simple" menu.
The change in the interpreter should also solve the issue #9031 which
were using the wrong item tree as the menu.
With EspPlatform, we need to initialize the FreeRTOS task used for
posting events before calling invoke_from_event_loop(). This is now done
basically in `slint_esp_init()` (well, the platform ctor).
The assumption preserved here is that the task that sets the Slint
platform is also the same task that ends up spinning the event loop.
This should fix the following (pseudo-code):
```cpp
void main()
{
slint_esp_init(...);
...
// used to crash because EspPlatform::task is only initialized in run_event_loop()
slint::invoke_from_event_loop(some_functor);
...
slint::run_event_loop();
}
```
- Implement @conic-gradient(color angle, ...) syntax
- Center is always at rectangle center (no center_x/center_y parameters)
- 0 degrees starts at north (12 o'clock position)
- Support Slint angle units: deg, rad, turn
- Software renderer: Full native implementation
- Qt backend: Native support with angle offset correction
- Skia backend: Native support with angle offset correction
- FemtoVG backend: Fallback to solid color (first gradient stop)
ChangeLog: Added support for `@conic-gradient`
Fixes#3957
clang++.exe doesn't understand the `/bigjob` flag.
So use generator expression to only pass the flag with MSVC and pass the
correct flag with other compiler (I did mingw as well just in case)
Fixes#8981
Just like with Rust.
This Fixes the C++ opengl_texture example. Also improve advice for C++ OpenGL examples to explicitly select the FemtoVG GL renderer
Fixes#8901
This is more intuitive that the C++ default, especially in light of additional output languages in the future.
To be on the safe side, this also passes the explicit -f cpp on the CMake side.
- Use a version of FemtoVG that uses WGPU 25
- Rename the unstable-wgpu-24 feature and wgpu_24 module
- Fetch bevy from a revision on master branch that switches to WGPU 25
- Move the bevy example out of the common workspace: That way users of the repo don't get bevy pulled from git, unless they want to build the bevy example.
Missing feature:
- conversion between Value and enums
- conversion from value to Model
- Compatibility with the testing framework (get the `VRc<ItemTreeTable>` from an instance)
CMake 4.0 remove some deprecated code < 3.5
Catch2 old version still depend against cmake 3.0 + deprecated method.
Necessary to increase version otherwise when we try to compile
example with cmake 4.0 it will failed to configure it
This ensures that the binary directory path isn't exposed in the
target's `INTERFACE_INCLUDE_DIRECTORIES`.
This prevents CMake errors when we `install` a target with generated
Slint sources in the include directory:
```
[cmake] CMake Error in slint/cpp/CMakeLists.txt:
[cmake] Target "slint-demo-cpp" INTERFACE_INCLUDE_DIRECTORIES property contains
[cmake] path:
[cmake]
[cmake] "/path/to/build/slint/cpp"
[cmake]
[cmake] which is prefixed in the build directory.
```
This adds an icon that is displayed to the left of the title, and is
also shown for Menus are inside of a parent menu.
Closes#7791
ChangeLog: Added icon property to MenuItem and Menu
For the slint-compiler, we use ${CMAKE_SYSTEM_PROCESSOR}, which on Windows is - unfortunately - derived from the PROCESSOR_ARCHITECTURE environment variable, and
thus AMD64 or ARM64. Fix the package suffix on the CI side.
We could try to make the cmake variable to known values and then arm64/x86_64, but I'd rather stick with less exceptions when these names are not really visible in the documentation or our users.
The same applies to the C++ packages, where the CMake/Windows suffix (AMD64/ARM64) works better with FindSlint.cmake's use of the corresponding variable.
Similarly, the tool binaries were called
slint-viewer-windows-aarch64-pc-windows-msvc, but neither the compiler, nor the rest of the triplet is needed, merely the architecture. So rename it to slint-viewer-windows-arm64 and x86_64. Here we don't need cmake and can use the "correct" suffixes.
Python is missing, otherwise this builds windows arm64 binaries for the
tools, C++ packages, slint-compiler, npm binaries, and lsp binaries for
the VS code extension.
Because some crate in our examples are using the edition2024 resolver
with no way to remove them without removing the exmaples from the
workspace, this means that effectively the C++ build which needs to run
the cargo metadata on the workspace, doens't build anymore with the
rust MSRV
ChangeLog: C++: requires Rust 1.85
This exposes FocusReason to .slint, and adds it as an argument to focus-event-changed callback on FocusScope to close#8387. It also adds two new callbacks, focus-gained and focus-lost, which are identical to focus-event-changed but are only invoked on focus gain or loss respectively.
In addition to this, it removes the FocusEventReason::AccessKit variant, replacing it with the mouse variant to hopefully make AccessKit more compatible with any Slint code that will use FocusEventReason.
Finally, I added two tests based on focus_change_event.slint, one for testing the FocusEventReason argument and another for testing the new callbacks.
close#8387
ChangeLog: Added `focus-gained` and `focus-lost` callback to FocusScope. Pass an `FocusReason` enum to the FocusScope callbacks
Closes#5992
Adds the enum FocusEventReason and makes it an argument for FocusEvent. This reason could eventually be exposed in Slint to solve #8387.
Using the focus reason tracking, I also added a select all on keyboard focus for TextInputs (except on macOS), which should close#5992.
ChangeLog: TextInput selects its content when focused with the keyboard on Windows and Linux
We currently forward declare classes as we use them in functions.
But this breaks if classes with the same name were declared in the
parent namespace. As shown with this example
```C++
// Uncomment that line to make the code break
//struct SharedGlobals;
namespace ns {
// Is that a forward declaration in `ns`?
// Depends if it was declared before in the parent namespace
void foo(struct SharedGlobals *x) {}
// Actualy define ns::SharedGlobal
struct SharedGlobals { int x; };
int xyz() {
SharedGlobals globals;
foo(&globals);
}
}
```
So make sure we forward-declare the classes properly to be more robust
and be able to include generated file with namespace after a file
without namespace
CC #2909
To be compatible with the 2024 edition, we need to wrap the
`no_mangle` attribute in `unsafe()`.
The parsing for that in cbindgen was only added in the version 0.28,
but we couldn't upgrade cbindgen before because of a regression in
cbindgen 0.27 that prevented us from upgrading.
Now that cbindgen 0.29 is released with a fix, we can prepare for the
2024 edition
This is still experimental API, but just have a copy of all arguments in
a plain struct that the C++ code can operate on.
(Because previous refactor of the interface had made it hidden from C++)
