When the output layout changes, it's possible that the bottom panel
will float in the middle of the screen, e.g. left edge of the panel
touches the left screen edge while top and bottom panel edges touch no
screen edge.
In that case, XdgToplevelWindow::strutRect() will erroneously indicate
that the left strut rect is valid, while it's not.
Since the strut area is garbage, Window::checkWorkspacePosition() may
incorrectly move and resize windows during output layout change.
The proposed heuristic will fail with square panels, but those are rare
and the only way to detect the correct strut area would be to use the
layer shell protocol.
Requires clients to have the
X-KDE-Wayland-Interfaces=kde_lockscreenallowed_v1 set in their desktop
file, then they will be able to use the kde_lockscreenallowed_v1
protocol to raise any surface above the lockscreen.
The protocol has only 1 method, raise_surface to do exactly that.
Makes it possible to implement
https://invent.kde.org/teams/plasma-mobile/issues/-/issues/98
On wayland, we are already restricting the rendering of windows that
aren't supposed to be shown when locked, so we don't need to keep the
lock screen on the unmanaged layer.
plasmashell may see new output layout before kwin_x11 and move desktop
windows accordingly. If that happens, the desktop windows will have old
outputs in Window::output() property because the Workspace doesn't
re-check outputs if the output layout changes.
In order to fix the Window::output() property getting out of sync,
re-check the current output after the output layout changes. It should
also fix a visual glitch in the slide effect caused by
EffectWindow::screen() not being correct.
The Window::moveResizeOutput() property is used to track the output
where the window is expected to land after the move or resize operation
completes.
This can be used to decouple the current output from the next output,
which allows us to send better xdg_toplevel.configure_bounds events or
make windows stick to outputs while keeping Window::output() in sync
with the current output layout.
Right now the Zoom effect's "zoom in" action is bound by Meta+Equals,
which makes sense for ANSI US keyboards without numberpads which make
you hit the Shift key before you can get a plus sign, and pressing it
without Shift gets you an Equals sign.
But some ANSI US keyboards have a numberpad with a Plus key, and many
other keyboards without numberpads also have a Plus key, so we should
allow users of those keyboards to trigger "zoom in" as easily as users
of ANSI US keyboards.
An application that does not support text-input has no way of
communicating with the input method, so even if you show the input
method the application receives nothing. As a fallback, instead send
fake key events so the application still gets something at least.
The key events are synthesised based on the text string that the
input method sends, which may result in things that do not actually
correspond to real keys. Unfortunately I do not see a way around that.
CCBUG: 439911
Xcursor loading can get stuck in an infinite recursion if index.theme
file indicates that the theme inherits itself.
In order to prevent that, keep track of the loaded so far themes and
avoid loading already loaded themes.
BUG: 457926
When a window that is on a different virtual desktop than the current one gets
activated, the current behavior is that the active virtual desktop will be switched
to the one the activated window is on. This may seem reasonable for a scenario where
the user explicitly intends to activate an existing window on a different desktop.
However, the following scenario is also (perhaps even more?) common: When an
application responds to a launch command by requesting to activate an existing
instance instead of opening a new one (such as Firefox or KDE System Settings), an
existing window on any desktop will get activated even when what the user had in
mind was opening a new window (on the desktop they are currently in).
This means that opening an application, such as following a URL or accessing a
system setting, unexpectedly results in the user being teleported to a different
virtual desktop. This can be very irritating. The more expected behavior for these
users would be to have windows always open on the desktop where they are called
from. That's is what this commit adds as a new option.
BUG: 438375
FIXED-IN: 5.26
Window::handleInteractiveMoveResize() calls setMoveResizeGeometry(),
which breaks in a way the encapsulation.
This change refactors geometry handling in handleInteractiveMoveResize()
so the next geometry is computed in a temporary variable and the move
resize geometry is updated either using move() or
doInteractiveResizeSync().
If the wl_output has been removed, kwin can crash all Qt clients by
sending a wl_output.done event. Also, it makes no sense to send output
events after the corresponding output has been removed.
CCBUG: 451028
we are searching between m_oldScreenGeometries.cbegin() and
m_oldScreenGeometries.cend(), so the result can't be compared
with m_oldScreenGeometries.end()
The xwayland data bridge tries to be helpful and convert some mimes.
However, that mime conversion code is buggy, and it appears like
Thunderbird can send text/x-moz-url in format, which our bridge doesn't
handle properly.
However, mime type conversion is completely out of the scope of the
compositor. We also can't keep up with various mime types. Given that
X11 clients already must handle _NETSCAPE_URL and text/x-moz-url, this
change removes our mime type conversion helpers. For the record, neither
wlroots-based compositors nor mutter perform such conversion either.
With this change, kwin will send text/x-moz-url and _NETSCAPE_URL data
as is.
BUG: 458226
It needs [1] from plasma-wayland-protocols.git or fails with
"outputmanagement_v2_interface.cpp:214:50: error:
'error_already_applied' was not declared in this scope" otherwise.
[1] f882bd942283262c27811a937e0d674d365ed72a
If multiple properties that affect the geometry change, then the
Output::geometryChanged() signal will be emitted multiple times, which
in its turn may force the Workspace to re-arrange windows, etc.
With this, the geometryChanged signal will be emitted in more expected
fashion only once as long as relevant property changes are batched.
Backends aren't the right layer to take care of placeholder outputs, and
don't really have enough information to do it either. This also fixes a
crash, because the placeholder output currently gets created too late
Currently, the main user of these two functions is the X11 standalone
platform.
This change ports that code to Workspace::geometry(), which is not great
but the X11 backend already depends on the Workspace indirectly via the
Screens. Not sure if it's worth making the standalone X11 backend track
the xinerama rect internally.
