When opting into the Skia renderer, we default to metal on macOS and D3D on Windows.
However if you want to develop a cross-platform application with Skia and
for example rely on OpenGL to be able to implement an OpenGL underlay or overlay,
then we need the ability to explicitly opt into skia's GL renderer.
cc #1445
We used to have SLINT_FEATURE_BACKEND_GL_ALL, but when we introduced the
renderer and event loop distinction in the features, we removed the "all" suffix from
the event loop that includes x11 and wayland support.
When building against a Yocto SDK, CFLAGS isn't set, only CC. When
building inside Yocto, CC is set to just the target compiler and CFLAGS
contains the target specific options. Just like with commit
5bc56a3924 we need to cover also
HOST_CFLAGS by making them empty.
Split backend-gl-* into eventloop-winit-* and renderer-femtovg.
The old feature names are still available.
For consistency eventloop-qt and renderer-qt are aliases for backend-qt.
We changed the MSRV in the last release because some dependency depended on
Rust 1.59. But that did not concern the C++ build, for example.
Now that we rely on rust 1.59 in our own code, we should make it explicit
so that the compilation error show the proper error
... even if the old value holds the same value as the new value
This fixes test_cpp_bindings_two_way_priority_default
Also add a C++ unit test that tests the Property type specificaly
This avoid repeating the enums both in the compiler and in
the runtime library, and register them in a bunch of other places.
So it should be easier to add enums and enum values
Since cbindgen doesn't see through the macro, generate the enum
manually
This isn't always needed, for example when using only the interpreter API,
and its dependency to native libraries on Linux (namely fontconfig) makes it difficult to cross-compile with
CMake.
While cargo is invoked correctly for the native binary build, the library search paths
coming from CMake will be target specific, not host specific.
So for now this provides a way of disabling the compiler.
As per rust-lang/cargo#5045, cargo does not set soname on created
cdylibs. We use corrosion to import our .so into CMake, which ends up
passing the absolute path to the .so to the link line of the
application. Due to the lack of DT_SONAME, this means that DT_NEEDED of
the application contains the full path to libslint_cpp.so. This is
sub-optimal for example for building Yocto SDKs, the build paths should
not end up in the created binaries.
The library should be located using the linker's search paths and the
.so name. For convenience, the application can use rpath to extend those
search paths (and usually CMake already does that), but there is no need
to code the absolute path to the library.
Set the IMPORTED_NO_SONAME CMake variable to work around this.
This can be verified with the steps as in #1066.
Fixes#1066
* Build the backends without rtti unless needed
Only the interpreter needs the rtti generated code.
* Since `SlintElement` emits `#[cfg(feature = "rtti")]` tokens, each
crate using `SlintElement` needs to have an `rtti` feature.
* The selector gets backend specific rtti selection features, in order
for the interpreter to enable them.
* Enable rtti when building the C++ project with the interpreter enabled
With the help of dark-light crate this is now exposed as dark-style
boolean property in NativeStyleMetrics.
Co-authored-by: Olivier Goffart <olivier@slint-ui.com>
Co-authored-by: Simon Hausmann <simon.hausmann@slint-ui.com>
