use adjustSize in updateMinimumWidth et al.
changing tooltip content updates sizeHints
using setGeometry is immediate, and will kill the animations.
for dialogs other than tooltips there is no change since adjustGeometry
is just setGeometry
Change-Id: I3e6310f12f76e400f2663b8409a2bbc7e7398f39
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
The code in Button is
panel.implicitWidth: max(label+borders, backgroundImplicitSize)
by setting the background implicitSize to be max(size, labels+borders)
we just duplicate the functionality.
This worked, but icon only buttons became smaller because we weren't
setting the implicitHeight of the label properly.
(two wrongs were making a right)
We need to move the RowLayout inside an Item as we are modiyfing the
preferredHeight of RowLayout, but this doesn't sync back to updating the
implicitHeight which Button.qml uses.
This fixes all binding loops and the rather broken icon only flat
button.
Change-Id: Id2f9c2ab37b2280ee69dc1473f388fe686e3327e
return a size rounded tothe nearest inferior standard icon size.
sizes larger than iconSizes.huge, it will be returned unmodified
Reviewed by: Kai Uwe Broulik <kde@privat.broulik.de>
Change-Id: I85c575ea1cc7965ae9bede9e5a8b7b4cb342580e
when we check if a position is in a screen, we need
the whole screen geometry, panels included, otherwise if we pass
a coordinate under a panel, it will think no screen is there
Change-Id: I802a2bec4ae44b583eafdc309934e67b620cc463
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
revert part of
306e353fe6
if a framesvgitem has an implicitsize explicitly set, it shouldn't be overwritten
Change-Id: I931ca8acafdc2f6908945d03fca97487ced22988
As with containment, make sure Containment::applets()
is always sorted by id, to have the least sursprises possible
it adds a test
Change-Id: Ib1aeeff7c70bb6969b32b2fef8557889a43edf09
the order in which containments were restored used to be quite random:
ensure that's ordered by id this makes the shell startups be more reproduceable
from one to another, if a new containment arrives, ensure it's inserted
maintaining id order
containment::appelts() will need the same treatment
adds a test as well that checks the order is right
Change-Id: Ie1b278e5b83d7e3645f7293bf6d030aa7f43a221
if a containment's lastScreen is not -1 (and a valid screen)
*and* its activity() is not the current one, its QML
will *not* be loaded, therefore it would dangle blocking
corona::startupCompleted until the activity is selected
Change-Id: I6757d29240a012377e9ff0a22fe16541ea712ee6
* never enable all the borders just to take margins, there is fixedMargins for that
* redo ResizeOrigin: Dialog needs to sync from both sides: when the mainItem gets resized, *and* when the window gets resized (syncing mainItem)
* don't crash when there is no Layout: not all mainItems export one
* fix availableScreenGeometryForPosition()
Change-Id: I09370e33a3e8d03675b60f14c6c5754f8491d52c
updateLayoutParameters's uses the borders in order to set the max and
minimum size, and therefore syncToMainItemSize should always be called
before it is ever called.
Also added code to not do anything if we are not completely initialized.
As with containment, make sure Containment::applets()
is always sorted by id, to have the least sursprises possible
it adds a test
Change-Id: Ib1aeeff7c70bb6969b32b2fef8557889a43edf09
the order in which containments were restored used to be quite random:
ensure that's ordered by id this makes the shell startups be more reproduceable
from one to another, if a new containment arrives, ensure it's inserted
maintaining id order
containment::appelts() will need the same treatment
adds a test as well that checks the order is right
Change-Id: Ie1b278e5b83d7e3645f7293bf6d030aa7f43a221
if a containment's lastScreen is not -1 (and a valid screen)
*and* its activity() is not the current one, its QML
will *not* be loaded, therefore it would dangle blocking
corona::startupCompleted until the activity is selected
Change-Id: I6757d29240a012377e9ff0a22fe16541ea712ee6
Containments with no applets will emit uiReady now
It adds a test as well that checks if this is the case.
There is still a case where the corona doesn't emit startupCompleted()
that's when there is more than one activity, but that, as well the test
will be adressed by another patch on a different part.
Change-Id: I4d83aa612c29fb0f441d11681bc5aba241370bc3
Setting the implcit width to be the same as the current height is very
easy to end up looping.
actual height of the background is set by the base style, which is based
on the implicit sizes anyway.
BUG: 338750
Change-Id: Ic7606588cec09c6ff16515c208efe576466d31d6
still catalog actions by type
the order is still not exactly the same, but that's not possible, since the action order is decided in the context menu plugin and there are some actions only in the toolbox
CCBUG:338585
We are in a strange cycle when we have a visual parent. In order to
obtain our position, we need to know our size. Our size depends on the
borders visible. The borders visible depend on the size.
When we do not have a visual parent this is not a problem as we do not
have a position where we are supposed to be.
In order to solve this cycle, when we have a visual parent, we typically
assume we have all borders, call popupPosition, move to that position
and then use that new position to figure out the borders, get the new
size (incase any borders have changed) and move again. This double
moving is not good. With that patch, we still do the same but we avoid
moving twice.
We seem to have cases where once the dialog is visible and the visible
event is over, then the width/height updates itself, so we need to
reposition the dialog appropriately.
The functions are often called a number of times before the
component is actually completed. There is no point of this.
Also added a function updateLayoutParameters which update all 4
of these in a more efficient manner. There is a certain amount
of code duplication between those 4 functions and this one, but
that can be fixed in another patch.
- updateTheme should always be called the frameSvgItem's size has been
upated. It uses the geometry of the frameSvgItem. Also updated the
documentation.
- When a dialog has a visualParent, setting the position of the dialog
is slightly compilcated. In order to set the position we have to give
the function popupPosition the size of the dialog so that it can
determine where to place it, however the size of the dialog depends on
the position as some of the borders are drawn depending on the
position. We have a circular problem.
For now we're solving this by tempoarily giving the full size with all
the borders in the case when there is a visual parent.
Remove the timer and call syncToMainItemSize directly whenever it used
to be called. We avoid the extra event loop this way. This probably
breaks somethings, but we can figure that out and add tests for that.
The only place it is now used is when the window x/y position changes.
There is now a dedicated function to handle that.
This brings us one step closer to removing the entire sync timer
