I do not connect to the window directly because I
want the connection to be gone when `InterfaceWindowHandler`
is gone. This is particularly important if
`InterfaceWindowHandler` is created multiple times
with the same target window, as we are not using
unique connection (can not, due to lambda slot).
- Since hiding the window destroys the wl_surface (before Qt 6.9), this causes
crash on Wayland (adjustments after video window setup is complete).
- With `CompositorX11`, adjusting a flag (such as always on top) and then
(immediately after) toggling the visibility of a window breaks the window. This
is a problem when, for example always on top and client side decorations change
together.
Although it is stated that "some window managers don't like to change frame
window hint on visible window", I have not observed an adverse behavior on X11
(Qt 6.2 and Qt 6.8), and Wayland (Qt 6.8) with KWin X11/Wayland 6.3.1. If this
is a problem of a certain window manager, the workaround should be only done
for that window manager and not in all cases.
At the same time, Qt does not seem to state that adjusting `Qt::FramelessWindowHint`
needs to be done when the window is hidden. So I believe that this should be
safe to proceed.
`QWindow`'s `wl_surface` gets deleted when `QWindow::hide()`
is called.
This is an exceptional behavior, and can be considered
a bug because destroying the window resources is tied to
`QWindow::destroy()`, calling `QWindow::hide()` should not
destroy the window's resources.
We are intercepting and inhibiting the close event for several reasons:
- Idle inhibit case (not inhibiting close used to crash at least Wayland).
- Video window using resources of the interface window case (Wayland, DComp).
Furthermore for the latter case we postpone destroying the window (hence
closing) even more, to the point destroying the window does not cause harm
with regard to the video window (fdb0a981 for DComp, 6923be9b for Wayland).
Because of this, the time between user clicks on the close button and the
window effectively closes is too much for responsiveness.
I propose to hide the window until destroying (and closing) to make close
more responsive. This should be fine because hiding should not
release the resources, as the default value of
`QQuickWindow::setPersistentGraphics()` is true and we are not overriding
it and we do not expect to override it as well.
I have also checked if this would cause saving the window state as hidden
before closing. However, `QVLCTools::saveWindowPosition()` does not save\
it so it should be fine.
We can use the transparent area to restrict the client
size and use that remaining extra size for resizing.
This size needs to be adjusted with regard to the dpi.
Note that on Windows 10 and Windows 7, this brings
borders.
`QWindow::show()` does not necessarily care about the state
of the window, but rather uses the default behavior for the
platform.
Since we adjust the window geometry and states before the
window is shown (which is the expected behavior, as otherwise
the window would get adjusted immediately after shown), using
`QWindow::show()` potentially overrides the window states
nullifying the behavior of the interface starting maximized.
... so that the interface window does not change its size
from the default size the platform window determines to
use.
Currently, the interface window gets resized immediately
after it is shown. This does not make any sense, the
target size should be set before for the window so that
the window is shown appropriately when it becomes visible.
When `qt-close-to-system-tray` is set,
the application would not exit on close
event, but rather the window becomes
hidden.
This setting is not enabled by default,
and is only applicable when `qt-system-tray`
is also set.
I believe that with the media library,
this setting becomes relevant to keep
one instance open rather than closing
and re-opening. Currently, even if the
user does not want to close the application,
the inclination is to close the application
since the window occupies space in the
task bar.
Previously this condition was only working for QQuickControl(s). But we might want it
to work with a non Control component, like a TextInput. In that case we declare
a 'visualFocus' property manually and bind it to a parent Control 'visualFocus' property.
InterfaceWindowHandler isn't receiving mouse events from the QWindow on X11, now
that we have CSDMouseStealer.qml which properly defines the resize areas, moving
the handling of resize areas from C++ to QML solves this issue and avoids having
the behavior handled in two places.
Fatih Uzunoglu
Ashutosh Verma
Pierre Lamot
Prince Gupta
Yann Lochet
Romain Vimont
Benjamin Arnaud