It makes sense for ToolBar button in CompactRepresentation, because
background depends on it, but it is useless for custom AbstractButton
which has no special code handling this value.
Not sure what exactly didn't work back than, not currently on Qt 5.15
everything seems fine.
Binding.RestoreNone is not the most recommended[1] value, but it
replicates the behavior of one-time assignment which was happening in
Component.onCompleted handler.
[1]: https://www.mail-archive.com/interest@qt-project.org/msg36486.html
MenuDelegate is a QQC2.Control's subclass, which is perfectly capable of
handling hover and press events on its own. Besides, few extra
properties and a custom signal make it feel like a dedicated component
which it really is.
Not sure how much (if at all) this makes sense performance-wise, but at
least the code looks cleaner and there are no duplicating components
anymore.
State enum is mutually exclusive as it is, so there's no way there could
have been more than one FrameSvgItem on screen at a time.
Generally, this property should be set on every Text component that we
write. It avoids ambiguity and extra potentially expensive parsing step
with heuristics. Here, we know for sure that the label is in rich text
format.
Text.StyledText format is computationally cheaper than the Text.RichText,
while still getting its job done: displaying the underlined letters when
Alt is key pressed.
`void *` casts into anything but `QVariant::value()` (most of the time)
does a metatype check which needs to match.
Also, we need to unwrap the `QPointer`.
BUG: 453301
28537cf3ff made the color dynamic, but
neglected to respect the Plasma color scheme, if any. This causes
problems with Plasma themes that have their own colors and don't
respect the systemwide color scheme, such as Breeze Twilight.
Fix it by using the appropriate colors from the PlasmaCore color scheme
object, not the systemwide object provided by Qt.
BUG: 453348
FIXED-IN: 5.24.6
Kolourpaint has hidden "Tools" menu, which would show up in
global menu otherwise.
Moreover, don't `void*` cast so QML can access the `QAction`
BUG: 443505
There's no need to reconstruct the entire menu, when it exists already.
Also shows correct behavior on Wayland because the imported menues have
correct parents compared to the new one.
BUG:438467
When the mouse hovers the appmenu item, the text color should be inverted to the background
color. Before this commit, the text was still the same color as the "REST" state, making it
difficult to recognize.
That's in a plugin we don't link against here, we only see its header.
This happens to work with Qt5, but Qt6 wants fully defined types for
properties. Use a QAbstractItemModel pointer instead, we only access that
API anyway, and for QML the difference doesn't matter.
In Wayland session data sources for modifier keys might be unavailable,
in which case the whole `source.data.Alt` is undefined. Standard
JavaScript try-catch didn't help much, because short-circuiting
operator && simply returns left-hand-side `undefined` value which is
falsy. It used to spam error messages to a console at a rate
proportional to the number of top-level menu items:
file:///usr/share/plasma/plasmoids/org.kde.plasma.appmenu/contents/ui/main.qml:112:17:
Unable to assign [undefined] to bool
Amends 156415f377