Since we now use an orthographic matrix as main projection matrix, the
glide and sheet effects don't really work as intended anymore. To fix
that, copy over the old perspective matrix and use that as base rather
than the current orthographic matrix.
It is quite a bit easier to reason about the conversion to device
coordinates when we actually have code that does that, instead of
implicitly assuming OpenGL handles it. Additionally, it means we don't
need to convert back to logical coordinates again when we're rounding
pixel values.
Rather than a perspective matrix, which is rather unexpected when coming
from something like QtQuick. Generally, when doing 2D you want an
orthographic matrix so Z values do not matter.
Apparently this was originally done for 3D effects, but there are only
two of those remaining (glide and sheet) and for those, the effects
themselves can set up a perspective projection matrix.
If we are using the software renderer
QQuickWindow::createTextureFromNativeObject returns null. We already
checking for kwin using GL compositing so we can expand to check
QtQuick's usage.
reconfigure is hooked up to a config watcher that is applicable on X11
and wayland.
A runtime check is added to reconfigure, if we're not initialised we
have nothing to reconfigure. initialise calls reconfigure at the end of
the method.
Since QPointF can have values that exceed INT_MAX, "distance <
minDistance" may not be triggered for the first output.
In order to make Workspace::outputAt() more robust to such extreme
cases, this patch changes the type of minDistance from int to qreal to
avoid truncation and adds an explicit check to initialize bestOutput
when we see the first workspace output.
It would be also great to add size hints sanitization code in kwin, but
it can be done later.
BUG: 460446
---
Should close:
* https://errors-eval.kde.org/organizations/kde/issues/321
* https://errors-eval.kde.org/organizations/kde/issues/341
When the slide effect paints a virtual desktop, it translates both
windows and the clip region.
Since the clip region slides too, the blur effect needs to be careful.
At the moment, the blur effect computes the blur region as follows:
- get the value of the blur region hint from client, map it to the
global coordinate space, and intersect it with the clip region
- apply translation and scale to the blur region
- pass the blur region to doBlur()
However, the translation transform must be applied before intersecting
the blur region with the clip region.
BUG: 460382
If the output is turned back on before m_turnOffTimer expires, the
dpms input event filter won't be reset and all input events will go to
the void.
BUG: 460322
AnimationEffect inherits from CrossfadeEffect as it may do a crossfade,
but it also has to perform non-crossfading activities with a custom
shader.
For crossfades we want to draw the old and new window, but this isn't
needed where the crossFadeProgress remains at 0.
BUG: 460277
Crossfade is now hanlded by regular scene painting, only by offscreen
effects. There is no need for scene code to have awareness and use a
more expensive shader.
In libinput 1.19, three new pointer axis events were added in order to
provide support for high-resolution scrolling.
LIBINPUT_EVENT_POINTER_AXIS is de-facto deprecated and new users of
libinput should use instead SCROLL_WHEEL, SCROLL_FINGER, and
SCROLL_CONTINUOUS.
Discrete deltas were replaced with v120 delta values. 120 corresponds to
a single discrete delta. Smaller values correspond to "partial" wheel
ticks.
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72
It's impossible to properly map EffectWindow::hasAlpha() to wayland
abstractions, where a window can have subsurfaces.
The main motivation behind this change is to move Window::hasAlpha() and
Window::depth() to X11Window.
At the moment, EffectWindow::hasAlpha() is used as a micro-optimization.
API and ABI breaking change in libkwineffects.
It's unnecessary on wayland and there's a bug in m_isDamaged
initialization. We need to set m_isDamaged to true otherwise
SurfaceItemX11 won't attempt to query the damage.
At the moment, the keyboard interception code in the effects system
relies on Qt code processing key events. However, since QDesktopWidget
is removed in Qt 6, this is a blocker for Qt 6 port.
This change ports the X11 backend to private xkb keymap as indicates in
the todo comment. It allows us to drop the last QDesktopWidget usage.
SlideDocks option was added after receiving negative feedback about
sliding docks. SlideBackground option was added to provide smooth
transition path for old users.
In hindsight, adding SlideDocks option was a mistake. It provides
excessive configurability in exchange for more code complexity.
With the virtual backend, it makes more sense to create outputs on
demand. It makes code clear, it would be also nice to use the virtual
backend for virtual outputs rather than have every backend implement its
own virtual outputs.
Qt 6 insists on this being exported, which in turns fails as this is
actually not implemented. There seemingly is an implementation, but that's
in a different namespace, so this can never have been used from the
outside anyway.
Currently, windows are not highlighted as expected in the window view
effect if the keyboard focus belongs to another screen view.
In general, it makes more sense to apply "Window.window.activeFocusItem"
constraint only to heap.selected.
With DamageReportNonEmpty damage report level, the x server will
send kwin a DamageNotify when the damage region changes from empty to
not empty.
The damage region will be made empty when SurfaceItemX11 calls
xcb_damage_subtract().
It appears like xcb_generate_id() can return us an already associated
XID, which eventually results in xcb_damage_subtract() failing and
breaking state tracking in SurfaceItemX11. KWin will no longer receive
DamageNotify events and some windows will freeze.
In order to make getting BadIdChoice less catastrophic, this change
makes the SurfaceItemX11 reset m_isDamaged after successfully fetching
the damage region. If xcb_generate_id() returns us a bad id, kwin will
try to fetch the damage again in the next frame.
BUG: 456511
It makes no sense to play the animation if the window is invisible. It
can also produce unexpected results if the window is not on current virtual
desktop as animate() will temporarily force the window to be visible.
If an invisible window is animated, e.g. minimized window, the maximize
effect will temporarily make it visible in order to play the animation,
which is unexpected.
Activities are loaded async. During this time any fetch of activity
information is incorrect as we will treat any settings as invalid.
We need to ignore attempts to set activities during this time, but also
refresh Window's concept of activities once we are loaded.
BUG: 438312
Display::outputsIntersecting() computes the logical geometry using the
oriented mode size and the scale factor, but OutputInterface's scale
factor is ceil()ed up, so the resulting logical geometry can be incorrect.
BUG: 459733
X/Y/Width/Height all get changed in the polish event so this only has
any effect in bindings before the first frame.
It seems this was leftover from development where we didn't have initial
values synced up properly.
This removes the "OpenGLIsUnsafe" flag and replaces it with a timestamp
that we can check to see how long ago we tried enabling compositing, so
we can retry it if a certain amount of time has elapsed.
BUG: 452344
The drm fd can get stuck in readable state, in which case the
QSocketNotifier will fire the activated signal as often as it can
leading to high cpu usage.
We need to read() the drm fd in order to make the socket notifier stop
firing QSocketNotifier::activated.
This change removes the m_platform->isActive() check to ensure that
drmHandleEvent() gets called, in general, it should be safe as we only
notify the outputs about completed pageflips.
BUG: 452726
With this change, when the specified output is disconnected, it will
just behave as if none were selected but when it's connected again it
will pick it back up.
BUG: 456857
QRect.contains(somePointF.toPoint()) will round the values.
This is problematic for the case of a mouse being at -0.4, we will
consider it in bounds for the screen, but obviously this doesn't match
any surfaces.
The detection and confineToBoundingBox need to behave the same and
floor.
BUG: 459328
Instead of InputMethod directly calling showClient() on the input panel,
call methods that properly show or hide the panel as needed, with readyForPainting
set appropriately. This removes the cases where it's shown without being ready for
painting, which causes crashes.
BUG: 459404
This makes kwin's behavior consistent with other wayland compositors
(sway, GNOME Shell, etc) and it's reasonable to provide all the
information about the data source before wl_data_device.enter. It also
makes Firefox happier.
Relevant discussion upstream: https://gitlab.freedesktop.org/wayland/wayland/-/issues/322
CCBUG: 445661
Window rules code can call maximize(requestedMaximizeMode()), in which
case the Window will emit clientMaximizedStateAboutToChange but the
maximize mode may not actually change.
This change moves the emission of of the clientMaximizedStateAboutToChange
signal to Window::changeMaximize(). The reason for doing so is that
window rules have the final decision what the maximize mode will be.
CCBUG: 459301
The last fix was not complete without registering the shortcut from the
start. It worked after changing it in system settings at runtime though.
Amends 984388dba4.
This may happen when all windows are minimized, and the effect was
started in "Window class on current desktop" mode (Ctrl+F7).
BUG: 459244
FIXED-IN: 5.26
KQuickAddons::ConfigModule sets the translation domain based on the plugin id
That is kcm_kwin_scripts. However the translation domain is kcm-kwin-scripts, which breaks loading translations
Also fix Messages.sh to extract from QML
BUG: 458438
The js code contains code such as
window.frameGeometry = {x: 42, y: 42, width: 100, height: 50};
However, QJSEngine doesn't know how to convert js object to QRect. For
that purpose, we need to register conversion functions.
So far, we kept registering converter functions only for integer based
geometry types, i.e. QRect, QSize and QPoint. In 5.26, Window was ported
to QRectF, QSizeF and QPointF, but the corresponding conversion helpers
were not added.
BUG: 459369
The desktopClient is a weak pointer and therefore can be null. This
makes sure that we are not calling a null instance of it.
It seems likely it was introduced here 45486ce515
This is a blind non-reproduced fix for the issue here:
https://errors-eval.kde.org/organizations/kde/issues/158/
Unlike D&D actions, this method does not return any feedback as to
whether an item drop was accepted by any other screen, and so whether it
is going through destruction process already, so the best we can do is
add another typeof/undefined check after calling that method.
Fixes the following error:
file:///usr/lib/qml/org/kde/kwin/private/effects/WindowHeapDelegate.qml:415:
TypeError: Cannot read property 'deleteDND' of undefined
DND was failing with the following error
file:///data/projects/usr/lib/qml/org/kde/kwin/private/effects/WindowHeap.qml:96: TypeError: Cannot read property 'mapToGlobal' of undefined
Change the render cycle for slide effect. Now, windows will be drawn on each desktop or not in the paintWindow() loop instead of the paintScreen() loop. This allows us to respect stacking order better by painting all of the same window together instead of per VD.
BUG: 457486
BUG: 458622
This special signal was designed to remove the need for such
bikesheddings and workarounds. Use it to react to user-driven changes.
BUG: 459202
FIXED-IN: 5.26
It is used in QML code, just like in windowview (Present Windows)
effect, but developers forgot to copy the implementation in C++
backend.
BUG: 459202
FIXED-IN: 5.26
Without window title being shown, background highlight should shrink as
well, otherwise it created a questionable gap at the bottom e.g. in a
Desktop Grid effect.
FIXED-IN: 5.26
Unfortunately, *Animator QML types have some problems with rendering,
sometimes affecting general smoothness, other times (like here, for me)
just not animating entirely. On my NVIDIA graphics system the animation
or a desktop returning from drag just looks like a freeze for a second,
then it suddenly jumps back to {0,0}. So let's just replace with less
optimal NumberAnimation which works fine.
FIXED-IN: 5.26
DragHandler does not travel along with its target heap, so it only
affects the cursor shape when the mouse pointer is directly over it; but
when a desktop is dragged far outside, the cursor resets.
Besides, this is how we already implemented it in WindowHeapDelegate.
FIXED-IN: 5.26
Use methods with semantic naming instead of raw data manipulation, and
make sure to perform clean up of DND data, so it won't haunt us back
later e.g. when a window delegate is recreated not because of a drag
of itself but due to a desktops rearrangement.
Because of const/non-const issues, iterator got invalidated in the loop,
which led to a crash.
Cases that trigger it: interaction with a thumbnail while the effect is
returning to initial state and shuts down. For example, slightly
dragging and releasing a thumbnail such that both TapHandler & DragHandler
would react and play each their own transition (yes, it's another bug);
or by pressing Escape key while dragging.
Having one state machine instead of two somehow simplifies the code and
makes it less fragile.
The new property `substate`, which replaces `thumbSource.state` still
supports imperative assignments that are so important for Drag&Drop,
and still triggers state updates. However, now a substate may not
become an active state: that behavior didn't make sense in previous
iterations, and has led to a glitch where a window won't resize during
return-to-initial animation. The glitch happened because two state
transitions were starting almost-simultaneously (and by Murphy's law in
the worst possible order, of course), and both animations were playing,
but one animation was supposed to to a property that is managed by the
other. But since QtQuick animations cache their from/to values before
they start, the dependent transition essentially didn't animate at all.
The Compositor is destroyed after the Workspace, so the placeholder has
shorter lifespan. We need to guard the destructor of EffectScreenImpl
from accessing a dangling pointer. For what it's worth, the destructor
of EffectScreenImpl was written with QPointer in mind, but it was never
added.
the existence of Window is bound to the one of workspace so it
will always be there.
We also need to check the window sizes before workspace is done
initializing,
otherwise when KWin restarts and there are maximized windows, they won't
be resized to take panels into account and will always span the full
screen.
Remember to release all resources before the wayland socket goes:
- release the seat as we give up a seat
- release the ssdManager
- release the output decoration with the output itself
Otherwise they leak and stay dangling.
When debugging something I realised that SIGTERM was always making KWin
crash like I'd never seen it crash. It turns out we are calling
QApplication::exit() on the signal handler which is highly forbidden as
the handler preempts the process altogether.
Use KSignalHandler instead which takes this issue into account.
Each screen has its own WindowHeap. So setting WindowHeap.activeClass
won't be visible on other screens.
In order to address that limitation, we could monitor
Workspace.activeClient property.
BUG: 455974
We use the PMF syntax so the isValid() check is unnecessary as the
compiler will notify about wrong signal at compile time. It makes
writing autotests feel less boilerplaty.
re-trigger the edge *only* if the user keeps the mouse still for at
least edges()->reActivationThreshold() - edges()->timeThreshold()
so that the user has to actually keep moving.
if the user keeps moving the cursor in the direction of the edge, it
wion't continuously retrigger it
BUG:457280
the Drag attached was set to active in a taphandler which didn't
accept touch, breaking drag and drop on wayland+touch
moving the logic on the other handler makes it work everywhere
This required a bit of a magic on the WindowHeap side to store and
restore global position of a WindowHeapDelegates' window thumbnails.
An additional property bool animationEnabled on a delegate level enables
the heap to restore position without playing unneeded initial animation,
just like the heap itself.
Windows that are being dragged or already returning form a drop are
positioned higher than others on a z-stack.
BUG: 453995
..so that they always match in size, regardless of different
combinations of drag&drop and animation states.
And also fix selected property to use id-qualified access.
Currently the Workspace processes output updates as they occur, e.g.
when the drm backend scans connectors, the Workspace will handle
hotplugged outputs one by one or if an output configuration changes the
mode of several outputs, the workspace will process output layout
updates one by one instead of handling it in one pass. The main reason
for the current behavior is simplicity.
However, that can create issues because it's possible that the output
layout will be temporarily in degenerate state and features such as
sticking windows to their outputs will be broken.
In order to fix that, this change makes the Workspace process batched
output updates. There are several challenges - disconnected outputs have
to be alive when the outputsQueried signal is emitted, the workspace
needs to determine what outputs have been added or removed on its own.
The proposed way to handle unplugged gpus allows us to ensure that
removed outputs' lifetime can be extended to the moment when the
Platform::outputsQueried signal is emitted.
Besides that, it's possible to extend this code a bit further to make
sure that output updates are batched when hotplugging multiple gpus,
e.g. after resuming, etc.
Separate trigger progress and semantic progress in gesture.
Move effect activation and desktop switching over to semantic progress.
Allow semantic progress to exceed 1 for overshoot in animations.
I've added VerticalAxis, HorizontalAxis, DirectionlessSwipe and BiDirectionalPinch gestures directions.
These are all combinations of other gesture directions that semantically work well together.
I've implemented these gestures as well as changed some labels and improved documentation,
Also,
Add vector signal to SwipeGesture
- Now only 1 GestureDirection enum
- Now only 1 registerGesture() call
- The 4 kinds of gesture (Pinch/Swipe) and (Touchpad/Touchscreen) in globalshortcuts.h/cpp are merged into 1 GestureShortcut
- Change from range to set of finger counts in gestures
No behavior should change, just a refactor.
When we have 0 opened apps, tab box only shows "Show Desktop". That element is a
special entry in the alt+tab list for minimizing all windows. When highlighting
it, panels temporarily become hidden, which does not make sense to do when it is
the only item in the tab box. In this case, do not temporarily hide the panels.
This makes it possible to show the input method when using a client that
doesn't support Wayland input methods (e.g. Xwayland).
This adds 2 dbus API entry points:
- activeClientSupported property: That tells us if the current client
doesn't support text-input-v*
- forceActivate method: forces the activation of the input method. This
configures the input method in a state that we can use to forward the
input method's keystrokes to the client, emulating a hardware keyboard.
BUG: 4399911
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.
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>
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
