We had the raw_window_handle_06 feature and functions in Rust, but there
wasn't an easy way to do the same in C++. This is especially useful for
embedding windows (such as browsers, 3D views, etc.) or just wanting to
access the platform's handles for other reasons.
ChangeLog: It's now possible to access platform native window handles
from C++, like a HWND.
No point in stuffing u16 into f32 just to reuse an existing type.
OTOH ArrayOfU16 can be reused for other things than grid layout
organized data, so give it a more generic name than
GridLayoutOrganizedData (we should do the same for LayoutCache, at
least if we ever reuse the type for an additional purpose)
The goal is to be able to enable feature conditionally with `i-slint-renderer-software/?...`
NOTE: this change the implementation of
`SceneBuilder::platform_text_fill_brush/platform_text_stroke_brush`
It was warning about `non_exhaustive_omitted_patterns`.
And it changed it to always return the brush color so gradient gets
converted to plain color instead of None.
This is the behavior with the non-parley renderer
Motivation: the git pre-commit hook is confused by the mix of 2021 and
2024 in the same workspace...
The only problem this raises is the std::env::set_var("LANGUAGE", lang) in
demos/printerdemo/rust/lib.rs, pre-existing but now explicitly marked as unsafe
because it actually is. Added a TODO there.
vec![] expands to Vec::new(), but expanding macros takes a bit of
time and takes memory in rust-analyzer. Also, the code was using a mix
of vec![] and Vec::new(), so this is more consistent.
This seems just be a typo, I think it's supposed check if _WIN32 *or*
_WIN64 is defined. Before compilation for Linux could easily pass
through because it doesn't have _WIN64 defined.
Shouldn't have any adverse affects since this was never going to work on
Linux in the first place.
They should be in the lines, but the problem is that this causes issues
in the .mdx files.
License header doesn't really make sense for .md files anyway
When using `. environment-setup-*` against a Yocto SDK, we end up with PKG_CONFIG_PATH set to the target sysroot and the pkg-config binary coming out of Yocto SDK and always locating packages in the target.
That means the build of slint-compiler fails as it needs font-config from the host system, when enabling support for embedding glyphs.
In this scenario, enable the compiler/fontique to dlopen fontconfig instead.
Instead of connecting to the X server, let's run the Python tests with the testing backend, like we do for test-driver-rust, test-driver-cpp, etc.
When building the Python package, pass --features backend-testing to Cargo, to forward to enabling the backend-testing feature in i-slint-backend-selector. That consequently enables SLINT_BACKEND=testing.
This allows to store the result into a different cache property
than the one that comes out of solve_grid_layout, which fixes
a binding loop when the text of a widget depends on its row or col
value.
Build editable builds as cargo debug builds, not release. This is faster
(because we don't need LTO) and in theory gives additional coverage to
debug asserts.
The `rust_attributes` in langtype::Struct is a bit wierd as it is only
used for rust code generation, yet is stored in every Struct.
Instead, read the `node` while doing code generation like we do in C++.
The previous code was ignoring the error lexing the code in the
attribute, and now we add a compile_error!
Separate steps and remove nox, so that
1. We first set up the env and build slint **once**
2. We run the fast lint/ty/etc. checks
3. We run the python tests directly
The generated file offers the following two pieces of functionality:
- Convenient front-end to slint.load_file() by loading the .slint file
(replaces use of auto-loader)
- More importantly: Type information for exported properties, callbacks,
functions, and globals
On loading, the previously generated API is compared to what's in the
.slint file and if the .slint file was changed in an incompatible way,
an exception is thrown.
A Python test driver is added which performs three steps with each test
case:
1. Generate python stubs and checks that they can be loaded with the
python interpreter and that `uv ty check` passes.
2. Extract expected python API out of pyi sections and compares them.
3. Appends any python code from python sections and runs them (this is
combined with step 1)
Fixes#4136
- Make `FontHandle` opaque.
- Avoid memory allocations
- Reword documentation
- Avoid indirection to i_slint_core (prevent documentation to be
repeated)
ammends for https://github.com/slint-ui/slint/pull/9762
