Crash seen in the wild. Can't reproduce, but could happen if the deletion
was triggered by some external event during a drag.
We're using a QPointer already, so it even makes sense.
Since the layout is nested, we need to look further for the main window.
I don't know however if restoring layouts even works with MDI.
Needs to be tested and implemented.
It's not supported but it shouldn't crash.
For #352, leaving it open still, as the reporter actually experiences
an assert, not a segfault. To be investigated further
1.7 introduced per-floating-window "flags" in the saved layouts. When
that value is not present in the saved layout, we need to fallback from
reading from Config global settings
The current behavior is great for when we want to apply an older
stored state to a different screen configuration. There,
scaling/shrinking the floating docks makes sense.
But we now also want to have more fine grained window
configurations and save/restore them more frequently. In those
situations, the screen config is the same, but the mainwindow may
or may not be full screen when the state was saved. In this case
we don't want to touch the size of the floating docks - most notably
we don't want to resize a "nearly fullscreen" floating window from
a state with a small main window when loading it into a state with
a fullscreen mainwindow - in such situations the floating window would
get resized beyond the available screen space!
Preventing the latter is probably required as a safety measure
independently of this patch, for situations where the relative
resizing is desired. This is outside the scope of this patch.
Fixes issue #334 and issue #337.
Won't add this directly into the library, as each project
has different requirements regarding this.
It's easy to do in application code though.
It required the user to move the mouse, which was OK but we can do
better.
Now, KDDW will automaticallt re-show the drop indicators if we're in
the middle of a drag operation.
Required for issue #334 and issue #337
I'm on clangd instead.
I could leave them there, but no idea if they are correct.
Once we have a developer using the MS extension then he's free
to maintain the options.
Usually, it's closed. "delete" isn't very well tested.
When it's deleted the container item becomes empty, so needs
to be resized to QSize(0,0) as well.
There's already a codepath for that but was too restrictive.
It now handles that case too.
Fixes#336
Previously we were updating the side bar overlay geometry only when the
side bar was closed. So if we open the side bar overlay, resize it, and
save/restore the layout state, we won't get the last side bar size.
Save it every time the frame is resized.
If the factory returned null for some dock widget, then the layout
would have holes. They need to be turned into placeholders, which
will be invisible.
Move the test into the QtWidgets guard. There's no point in making
it agnostic, since the bug is in the layouting.
When a main window is serialized, we get the geometry to be serialized
with MainWindowBase::windowGeometry. When the layout is restored, we
get the geometry of the current window with window()->geometry() and use
it to compute the scaling factor.
The values returned by MainWindowBase::windowGeometry and
window()->geometry() will differ if the main window is a native widget,
but not a toplevel window. In this case, windowGeometry returns the
geometry of the main window widget, not of its containing window.
Use MainWindowBase::windowGeometry when computing the scaling factor, so
that these geometries are consistent and the scaling factor is correct.
QScreen::geometry() is already in "virtual coordinate space", no
need to map again. Bug wasn't noticeable since most setups
have virtual top left at 0,0, so it was a no-op in most cases.
Fixes bug #321
No behaviour change for now, just moving.
Its usage is tricky, so it should only be used in one place, so we
can honour FloatingWindow::m_flags overrides too.
For issue #314
