You can assign a QAction as "action", this way you can just pass it e.g. plasmoid.action("configure").
However, when assigning a null action as can happen with kiosk restrictions, it would crash
as it assigns m_action the nullptr but never checks for that.
This patch ensures we always have a QAction, creating a new empty one, if neccessary.
Also deletes our own action if an external one is assigned
Differential Revision: https://phabricator.kde.org/D6608
This allows to limit the maximum width of a menu. It can be useful for instance
in task manager where long file names for recent documents will result in gigantic menus.
The property has a RESET method (which is called if you assign "undefined") which will
set it back to QWIDGETSIZE_MAX to remove the size restriction.
Differential Revision: https://phabricator.kde.org/D4257
Similar to KPasswordWidget in kwidgetaddons
Also fixes:
- the clear button still being clickable when not enabled
- RTL icons
- Updating the right margin correctly
REVIEW: 128660
Like KIconloader, support a Selected state, in IconItem,
as in all generic svgs/framesvg
it replaces the text color with HighlightedText and the
background color with HighlightColor
Change-Id: Id97a527405d2c3feed75a172f05547defdbf440c
REVIEW:127975
Since some time PlasmaCore had the very useful ColorScope class,
which can semi-automatically make children take colors of the
View, Button or Complementary color groups.
Unfortunately it didn't support dynamic reparenting, giving
wrong colors in some cases (see black on black battery on the phone)
even tough is a bit complicated, now by cascading signals down the
children tree, support on the fly apply of the new context upon
reparenting.
also add a manual test case showing text, rectangles and icons
dynamically changing color as they get moved from one scope
to the other
REVIEW:126654
Change-Id: I3d746b73eac55a359c4706fb719b4d5018677fb5
Plasma's Button has an extra property "minimumWidth" which is an extra
hint not in QQC to say "what is the size to exactly fit the contents".
(it's a bit confusing, as we can perfectly handle a button below it's
"minmimum" size)
This should be based on the size the contents want to be (the
implicitWidth), not how small the contents can go (which with is pretty
meaningless when our button can elide)
It got broken at some point recently.
BUG: 353584
Change-Id: I637898c3abf98183bbae30d8f15c4d72801a3650
REVIEW: 125698
QQC button heights are max(backgroundHeight, label + margins).
QQC lineedits are only from the background
We need to take the margins into consideration when deciding how high
the textbox should be otherwise we're effectively just ignoring what the
SVG says.
This means button and textbox on the login screen are now the same
height.
REVIEW: 125240
if there are transforms in the scene, to correctly compute the position the
transform is needed to be accounter for.
QQuickITem::mapRectToScene does consider tranforms.
this adresses bug 345787 where the toolbox may be rotated.
BUG:345787
Change-Id: I13a5509d95a7498382155abf3c3d195708de56a6
Given comboboxes use the same background as buttons they should use the
same text colour too.
This prevents a situation in Breeze where a ComboBox could get white
text on a white background when using a colourscope with complementary
colours.
Change-Id: I21502186178a32ce480cd3e838335451bf644c3e
Test is enhanced to also cover vertical bars. The ProgressBar does not yet use
the vertical assets since Qt just conveniently rotates the bar for us and
apparently just overriding the entire "panel" component is evil
REVIEW: 121085
the layout size hints can change all together, in any order possible.
the only way to have a deterministic behavior is to compress them
and do the sync of the size all at once.
also being sure to do a single adjustGeometry (one X call) instead of
separate setWidth/setHeight
a test for the issue is dialog_resizeWithParent.qml
BUG:339478
Change-Id: Ia7c3c55e40ff89971beb734dcd205df05bfba687
changine the minimum and maximum heights, causes the dialog to not be repositioned
at the correct position with the visual parent
Change-Id: Ib67e6b842f5b4e3563da2ae826aa0c358cc208f4
since when is not visible the dialog doesn't update its size
from the mainItem size, the minimum size should not be
updated as well, or the initial mainitem size will get lost
and the dialog will be initialized to a wrong size
Patch by: Vishesh Handa <vhanda@kde.org>
Change-Id: I272727fb4732474b102de64c9bfdddb7fc3906c8
A dialog can be resized for two reasons: the mainItem size changes, or the dialog size changes.
the first can happen programmatically, caused by the Layout, or just by assigning the width.
the second can be caused either programmatically, assigning the size of the dialog or externally by the windowmanager, that is the only one theat in the end has the only final control of the window size
Change-Id: Ifc5c7f683039f83d13a5046c10d6dd0227169542
REVIEW:120235
