In a LineEdit with a long text, when dragging the selection
to the point where the anchor scrolls out of view in the other
direection, it used to keep being visible, outside the LineEdit.
This commit fixes that by passing the clip rect to the java code
that positions the selection handles.
* Add support for the Back key on Android
Successfully tested with this code
```slint
forward-focus: my-key-handler;
my-key-handler := FocusScope {
key-pressed(event) => {
if (event.text == Key.Back) {
root.close();
}
accept
}
}
```
but also without (that was the hard part: letting Android
terminate the activity on Back if it's not accepted by slint,
which no longer happened after returning Some(...) in key_codes.rs)
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
Focus transfer via keyboard or mouse only works between visible items, but let's permit programmatic focus transfer and trust the developer to do the right thing towards the user.
Reported by ramayen at https://chat.slint.dev/public/pl/kaik88s9tbbaxp6mq9ht1ysw5a
... and call that during key event delivery.
Add `capture_key_pressed` and `capture_key_released` callbacks
to `FocusScope` to expose this functionality.
Add a simple test to make sure Interception of key events works as
expected.
Related to: #102, #6390
-- Problem: is using `vtable::VRc::borrow(&menubar)` the correct approach?
-- Problem: `VTableMetaDropInPlace` is not properly implemented for `MenuVTable`
-- Problem: Codegen for menus has not been updated yet
- Updated Context Menu code to use `VRc` so both sides are supported
- Removed the `show_context_menu()` and started using the existing `show_native_popup_menu()` stub. Changed (probably erroneously) the type of the context menu parameter to what was on original change.
- Created a `ContextMenuWrapper` for the case where have the generated `activate()` and `sub_menu()` calls (this is incomplete)
- Removed the `no_native_menu` infrastructure that I cargo culted.
This represents the better part of a day of trying to implement native context menu support with `muda`. I've been able to get a context menu to appear, with the following caveats:
- Only the Rust code generator is supported
- Only Windows is supported
- Menu activation is `todo!()`
- Root menu items seem to display a subitem whether they have items or not
I've been finding it challenging navigating the Slint object model, particularly in the context of code generation, and I'm sure in some cases I'm overlooking simpler solutions. So I was hoping that I could get some feedback (perhaps what objects I need to "lock on to") about how to pull this over the finish line.
Thanks in advance, I'm really looking forward to having a native context menu in Slint!
We had code on the window to reset the default-font-size property to the
default from the renderer.
For the Qt backend, the PopupWindow being their own Window, this code
was activated also for the PopupWindow's hidden default-font-size
property, which caused all PopupWindow's font to not follow the
default-font-size
Fixes#8855
- 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.
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
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 adds a `unstable-wgpu-24` feature that exposes WGPU types in the
GraphicsAPI enum, adds `require_wgpu_24()` to the backend selector,
and adds a conversion from `wgpu::Texture` to `slint::Image`.
The `require_wgpu_24()` function in the selector will be extended in the
future (before the next release) to permit specifying additional aspects
of the WGPU configuration.
Co-Authored-By: Olivier Goffart <olivier.goffart@slint.dev>
This is required to fix closing popup with the Qt backend, as we use the
window_adapter as a hack to get the root window_adapter (as opposed to
the popup one)
(That function was only used for the ComponentContainer and was not
implemented for C++ before)
Note that this reinterpret a
`Option<slint::private_api::WindowAdapterRc>` to just a `WindowAdapterRc`
This is because `Option` is only forward declared in C++ as it is not
generaly `#[repr(C)]`, but we assume (and assert) the usage of a niche.
As reported in https://chat.slint.dev/public/pl/ihnwtdgp7fb75k4aj5ou3p4idc
With usual copy/paste entries
We need to make sure that showing the popup window don't clear the
selection in the TextInput which happens if the TextInput gets a
FocusOut event.
`__CARGO_FIX_YOLO=1` is a hack, but it does help a lot with the tedious fixes where the result is fairly clear.
See https://rust-lang.github.io/rust-clippy/master/index.html#needless_return
```
__CARGO_FIX_YOLO=1 cargo clippy --fix --all-targets --workspace --exclude gstreamer-player --exclude i-slint-backend-linuxkms --exclude uefi-demo --exclude ffmpeg -- -A clippy::all -W clippy::needless_return
cargo fmt --all
```
This is a hacky approach, but does help a lot with the tedious fixes.
See https://rust-lang.github.io/rust-clippy/master/index.html#/unnecessary_map_or
```
__CARGO_FIX_YOLO=1 cargo clippy --fix --all-targets --workspace --exclude gstreamer-player --exclude i-slint-backend-linuxkms --exclude uefi-demo --exclude ffmpeg -- -A clippy::all -W clippy::unnecessary_map_or
cargo fmt --all
```
With the Qt backend, the PopupWindow has its own Window and the focus item is not
always set to that window. Resulting in the focus appearance, but the keyboard event
wouldn't be taken by that item
Fixes#7529
And call `extern crate std` when the feature is enabled.
I've read this is the good practice on how to do it.
So that the std prelude is no longer included automatically.
There is then less difference between std and and no-std build which
should avoid surprises in the CI when we use things from the prelude.
The downside is that there is a bit of churn in the tests
