Fixes#9005
Both `is-separator` and `is_separator` were on the HashMap of the value
struct for the MenuEntry. When lowered to actual struct, the `_` is
normalized, but then it depends on the order of the fields.
- 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!
The padding property is accepted but doesn't have an effect.
It was meant for future use but didn't get any use.
And people get confuse when they set it. (See #8829)
Closes: #8829Closes: #6288
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.
In 80de96488a (#3397) we introduced a new
error if we detect a binding loop from the Window geomerty to its layout.
But it looks like this causes a lot of error in existing project, so
make it a warning instead.
It will continue to be an error in the live preview as this will cause a
panic otherwise.
This commit also change the text of the error to include the actual
binding loop. I hope this makes it easier for users to see the loop and
help to fix it.
The Window geometry depends on its constraints, so its constraints
cannot depends on its geometry
This fixes Infinitely growing layout, and other panics
Fixes#3989Fixes#2902Fixes#8065
Replace ios specific cfgs with "apple but not macOS", dubbed
ios_and_friends, so that we also cover iPadOS, etc.. What those have in
common is that they don't have user-resizable windows. (We might want to
add visionOs in the future)
Also, simplify a few macos or ios cfgs with just target_vendor =
"apple", for what applies to all the operating systems.
The compiler was accepting the comparison of types such as color, or
struct, and then later we'd get rust compilation error or interpreter
panic.
Example seen in the crash reporter:
`internal/interpreter/eval.rs:257:35`
```
unsupported Value::Brush(SolidColor(Color { red: 0, green: 0, blue: 0, alpha: 0 })) ≤ Value::Brush(SolidColor(Color { red: 255, green: 0, blue: 0, alpha: 255 }))
```
Note that some code hapenned to compile with rust or C++.
For example, comparison of bool, or anonymous struct (represented as
tuples), or color represeted as int)
So technically this is a breaking change.
But this should be fine as this was not working in the interpreter and
this is a bug fix.
ChangeLog: Slint compilation error for comparison of types that can't be
compared with less or greater operator.
The layout pass needs to see when going over the layout, that these
properties are set. So inline the element that sets these properties if
they are not set in the base.
Fixes#8091
This is only exposed when internal types are exposed (such as in the lsp).
The plan is to make this public under a new name/global after the release.
Co-authored-by: Olivier Goffart <olivier.goffart@slint.dev>
By default it's enabled, of course. This property is not only added to
MenuItem, but Menu as well - since they can be nested. It's also
possible to select a disabled item, but it's hard to modify that since
it's logic is written in Slint. You should be prevented from activating
it with a tap or key press at least.
See #7791
You can not create this expression manually, but there
is a pass in the compiler that adds it to all set
properties in a compilation run.
All it does is basically associate an id with an expression,
so that we can then in a later step have the interpreter do
something with that information. Apart from that, it tries to
be as transparent as possible.
The LLR lowering removes that expression again, just so we can
be sure it does not end up in the generated live code.
Let further pass materialize them, and most likely remove them anyway.
That way, they can be properly set and read from the rest of the .slint
code.
Fixes#8080
This does some refactoring to allow builtin item functions to return a
value:
- builtin member functions are no longer BuiltinFunction, but they are
just normal NamedReference
- Move special case for them in the LLR/eval
Don't merge a property with a global property if it has a change handler
as we can't mobe the change handler in the global
Fixes#7784
If two property are merged that each have a change handler, we must
merge the change handler. (Note that the order in which they are being
called is not deterministic)
Fixes#7747
During the second phase, anything that involve @children should already
have been processed, so there shouldn't be anything left to inline.
But the children insertion point may be pointing to the wrong location
if some items were moved around (eg because of the `clip`).
So work it around by not accessing the children array at that indax that
might be out of range.
Fixes#7724
