if the heuristic fails (because the topleft of the dialog is offscreen)
use at least our screen()
the screen should be correctly updated now on Qt 5.3+ so should be
more reliable anyways (could be tried to remove the whole Q_FOREACH
at this point)
Change-Id: I29311f4767bde3e02ae7bcb54b400b72a8f190eb
always show full margins in dialogs
this is to make things look less cramped with screen and panel edges
since mouse still has to work on screen edges (fitts law)
in that case it forwards mouse events inside the actual content item
so things like menus at the edge of the screen keep working
Change-Id: I4b8a5a5bac92eadbaf7ad5b9b7dc0d5f364888c3
If d->applet->package().isValid(), then d->qmlObject->mainComponent()
is null.
This makes Plasma crash when a faulty plasmoid is loaded.
REVIEW: 120581
This is not completely correct.
however, when reparenting the mainItem containming window thumbnails
it causes serious graphical artifacts, like the "lost fonts" on
nvidia and fglrx
Change-Id: Id194f5e7863e4ed71792835a9a3cf9c6e4fa70ee
is the only event we get we know the window will already be visible
to set the flags to have actually any effect
BUG:335572
Change-Id: Id1b69a894295af59a681946df9d14ff7ed316526
setting a null parent to mainitems seems to screw up with their QQmlContext
the problem can be seen with the taskbar, that after fiddling with tooltips a lot, (like switching between pager and a task) it loses thumbnails and it starts to output on stderr
about ids that aren't accessible anymore.
Change-Id: Ibbb6d270fd2e20b5b6745e228f4010b74d3266c9
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
Dialog.h uses netwm_def.h in the header so it should be included by apps
that use plasmaquick implicitly
Change-Id: I55507f552025468dde32e4830a78e34dc35c03af
We only want to toggle our visibility until after all window flags have
been set, as some flags can only be set before the window is shown.
This patch caches and proxies the visibility flag and only update the
real visibility when the component is complete.
Change-Id: I4ce7744dc48afecf35db6679ca0991b7042e45a2
AppletQuickItemPrivate::compactRepresentationCheck() must not be executed before
the qml parse is over and rootObject is here: the creation of the full or compact representation
would go very wrong in that case
Change-Id: Ib72f7d25f570a1ae34ada3330080350384d5c1e8
CCBUG:339329
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
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
* 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.
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
When the minimumWidth/Height of the attached Layout of the mainItem
would change. The following events would happen -
- updateMinimumWidth is called
--> results in resizeEvent being called
--> results in syncMainItemToSize
--> results in slots connected to mainItem widthChanged
---> syncMainItemToSize + syncToMainItemSize being called a few more
times. It's not entirely apparent why at thist point.
This kind of logic is quite hard to follow and more importantly because
of the timers in the middle, an extra paint event is called. This means
the user can first see the window resize and then the item getting
resized.
This patch introduces a little bit of code duplication (can be fixed in
future commits) to clearly establish what updateMinimumWidth should be
doing -
* disconnect signals to make sure mainItem's widthChange is not triggered
* update window size + item size + borders
* reposition if required
The repositioning is useful as currently if a dialog becomes wider if
will not reposition itself and will overflow. With this patch we always
make sure the entire dialog is shown.
Minor Point: On testing without the patch the dialog does reposition
itself if it is not already overflowing. I suspect this is kwin moving
the window.
A test called dialog_minWidthHeighRepositioning.qml can be used to see
how the change occurs before and after.
