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
For the future Python generate, we need to know if a struct type is a
public Slint type, private perhaps, or custom. Instead of continuing
with string operations, an enum gives clarity what's what, and this also
emits removing some string matching to identify specific types.
Currently Ava is used to unit test the api/node project.
Vitest is already used elsewhere in the monorepo, integrates well with
Vite, is fast and automatically handles tests written in Typescript.
Replacing Ava would simplify how Typescript tests are performed.
This PR introduces Vitest to the project, sets it up to match Ava
(isolated process for each test) and ports just the window.spec.mts
file.
Later PR's will port the rest.
- Bundle translations for WASM/Android only (not for native builds)
- Load Noto Sans CJK fonts dynamically from GitHub at runtime
- Implement register_font_from_memory() with Result<FontHandle, RegisterFontError>
- Make API automatically available with std feature (no explicit feature flag needed)
- Export load_font_from_bytes() for WASM font loading from JavaScript
- Change from wasm_bindgen(start) to explicit main() call for better control
Fonts are loaded before app initialization to ensure proper CJK text
rendering across all major browsers without bundling font files.
Native builds load translations from lang/ directory at runtime.
WASM/Android builds bundle translations at compile time and detect
browser/system language automatically.
API is now available when std feature is enabled, since we always
have fontique with std. No need for experimental-register-font feature.
Coming from the QML world it was normal to just throw a bunch of QML
files into a single CMake target without any thinking. But with Slint, I
encounter into strange symbol conflict issues and thinking this was a
bug in our compiler.
In reality this was actually an acceptable limitation (see #2909) which
is fine... but this wasn't isn't mentioned anywhere in the CMake
documentation - so I never knew about this or the solution. I added a
new cautionary warning to let future developers know that in case of
symbol conflicts, they need to separate files into their own namespaces.
If you try to pass multiple files into slint_target_sources, some
generators may complain with a strange error like this:
ninja: error: build.ninja:226: multiple rules generate slint_generated_dialog_1.cpp
The reason for this was how the macro worked (and CMake scoping rules.)
While putting together the list of .cpp files to generate - which is 1
by default but is user-configurable - we append a list called cpp_num.
However we don't *reset* this list variable, so in each foreach
iteration we kept appending a new .cpp file and thus telling CMake we
were generating "slint_generated_dialog_1.cpp" twice, in addition to
whatever other file you had. We don't hit this issue with the other
variables like translation_domain_prop because they're set on every
iteration.
The fix for this is simple though, we can just set the variable to
empty.
