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
