when going in/out of fullscreen call updateAllowedActions to notify the
decoration of eventual allowed actions changed. this makes the shade
button reappear as needed
BUG:458844
When a buffer is damaged via damage_buffer we have to map things to
logical space. This mapping can involve floating numbers, most notably
with the X11 override, right now that's via a QRegion which is always
integer. For damage we always want to round outwards to the larger
space, not to the nearest space.
This might be the root cause of random ASAN errors in testQuickTiling.
From commit 617291c6974d232ee99c4c49e891ce16863e3d6e:
The internal EventQueue is a child of the registry object. This means
that after the registry is destroyed, all proxy objects in that event
queue are going to have invalid reference to it, which is not a problem
as long as the wl_display_dispatch() function is not called.
The wl_display_dispatch() function uses wl_proxy's queue reference to
enqueue incoming events to that queue.
Unfortunately, during teardown, the internal ConnectionThread may
dispatch events right after the registry object has been destroyed,
which can lead to a crash.
In order to fix the crash, we need to destroy all proxy objects and only
after that we can destroy the event queue. It's okay if wayland events
are dispatched in between.
i.e. the EventQueue object must be destroyed last to ensure avoid hitting
dangling pointers.
WindowThumbnailItem in scripting doesn't support any of the
'brightness', 'saturation', 'clipTo' anymore, so it makes
no sense to support it in the KCM's preview.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
- add missing entries for focus delay and multiscreen behavior
- add missing entries for window placement modes maximized and under mouse
- add missing entries for mouse actions
- remove entry for removed "display window geometry when regeometrizing" option
- reword explanation for window raising
- extend explanations for window placement
- hint at screen edges kcm in movement section
- hint at window rules in advanced section
- add more keywords
- some small wording, typographical and formatting changes
Currently, we effectively almost everywhere need DrmOutput outputs,
DrmVirtualOutput outputs are needed only in a couple of places. There's
not a lot that we gain from storing real and virtual outputs in one
list, it adds unnecessary casting, etc. Ideally, virtual outputs must
come from a different backend, the current approach is not scalable.
The Overview effect manipulates the opacity of the desktop bar and
search field along with that of the blurred background so that they
all fade in and out in sync, but Window View does not, leading to a
discrepancy between them that looks weird.
This enables again the crossfade between the old window picture and the new one in the maximize and morphingpopup effects.
It does that with the OffScreenEffect redirect() feature.
BUG:439689
BUG:435423
This std::sort() function traces its origin back to
cbbd684430. The sort step was necessary to
ensure that we get same configuration hash regardless the order in which
outputs were connected.
On the other hand, our KWinKScreenIntegration code already does that so
it seems excessive to sort outputs the second time.
Placeholder outputs are not rendered so they don't need render data.
Also, this simplifies the control flow when the last real output is
removed. The Platform::screensQueried signal won't be emitted inside a
Platform::screensQueried slot.
Things such as Output, InputDevice and so on are made to be
multi-purpose. In order to make this separation more clear, this change
moves that code in the core directory. Some things still link to the
abstraction level above (kwin), they can be tackled in future refactors.
Ideally code in core/ should depend either on other code in core/ or
system libs.
Other policy enums are declared in options.h so let's do the same for
placement policy. Besides consistency, another advantage of moving the
enum in kwin namespace is that the enum could be forward declared.
It is relatively expensive and there is no need to do it unless
there are actually windows that make use of the blur effect.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
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
