So we can locate the files relative to the .rs file instead of relative
to the Cargo.toml file.
For compatibility with previous version and older rust, still try to
locate files relative to the Cargo.toml for rust files.
The LSP will always auto-complete relative to the .rs file
The live-preview for Rust need to make the file absolute because it
isn't in the case of a macro
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
The definition of an Easing namespace allows to name an easing curve
outside an expression of type easing like, for instance, a struct field.
Closes#3943.
ChangeLog: Added an `Easing` namespace to reference easing curve outside of `easing` properties.
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.
- 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
-- 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 `ContextMenuFromItemTree`
- Moved `MudaType` to `internal/backends/winit/muda.rs`
- Stopped unnecessary use of `Option` when creating `context_menu_item_tree`
- Removed awkward Box<dyn> usage
- Using sp::VRc<sp::ItemTreeVTable> instead of recommended sp::VWeakMapped<sp::ItemTreeVTable> because the weak reference does not live enough to be activated
Outstanding issues:
- Root items are incorrectly all sub menus
- No longer needed ContextMenuItemTree needs to be removed
- MudaType needs to be moved
- Root menu items seem to be empty submenus, and are this not usable
- Root separators seem to be blank menu items
- `ContextMenuWrapper` works by virtue of passing `Box<dyn ...>` callbacks to them. This is clearly a hack to get around the challenges of using the "quote macros" from within `impl ContextMenuWrapper`
This is clearly not a complete and desirable solution (yet)
- 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!
Missing feature:
- conversion between Value and enums
- conversion from value to Model
- Compatibility with the testing framework (get the `VRc<ItemTreeTable>` from an instance)
When the SLINT_LIVE_RELOAD env variable is set, generate a component
that will forward everything to the interpreter instead of generating
everything.
Fix running the test driver rust with the SLINT_LIVE_RELOAD
```
SLINT_LIVE_RELOAD=1 cargo test -p test-driver-rust --all-features --features=slint/live-reload
```
This fixes the contents of the `n`-th repeater inside the
`ComponentContainer` to also show up in the `n`-th repeater *after*
the `ComponentContainer`.
The ComponentContainer is lowered to a Comonent Container and a
dynamic tree node. The tree node is managed manually and I messed
up the repeater indices since there were no entries in the repeater
array for the embedded components. That mad things hard to keep
consistent as components get merged.
This chnages that: It lowers a Component Container to Something like this:
```slint
ComponentContainer {
if false: Emtpy {}
}
```
This way the standard mechanismns make sure we have something to put into
the repeater list and that unscrews the indices, saving a bit of code along
the way.
The inserted repeated node is still marked as `is_component_placeholder`, so
that we can wire it up as needed.
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
From the v1.11.0 crash reporter:
There is a panic in
`target/x86_64-unknown-linux-gnu/release/build/slint-lsp-8494405be069a534/out/main.rs:115729:64`
```
called `Result::unwrap()` on an `Err` value: Other("Could not initialize any renderer for LinuxKMS <REDACTED: user-file-path> from Skia renderer: Error opening device <REDACTED: user-file-path>: No such file or directory (os error 2)\\nError from FemtoVG renderer: Error reading DRM resource handles: Permission denied (os error 13)\\nError from Software renderer: Error opening device <REDACTED: user-file-path>: No such file or directory (os error 2)\\nNo renderers configured.")
```
That line in the generated file is in
```
115728 │ fn window_adapter_impl (& self) -> sp :: Rc < dyn sp :: WindowAdapter > {
115729 │ sp :: Rc :: clone (self . window_adapter_ref () . unwrap ()) }
```
Relevant backtrace:
```
6 "core::result::unwrap_failed"
7 "slint_lsp::preview::ui::slint_generatedPreviewUi::PreviewUi::new"
8 "slint_lsp::preview::ui::create_ui"
```
So the theory is that user_init need the window for some reason.
(eg, could be needing the scale factor to conver sizes or some other
things that needs the window)
So make sure we do the test before calling user_init
