To clarify that the toggle action merely temporarily disables the blue light filter, rather than turning the schedule off permanently like the "Disbaled" setting in the KCM does, use "suspend/resume" terminology instead of "off/on" in the keyboard shortcut and OSD.
Follow-up on plasma-workspace!4262
CCBUG: 486647
Include a warning if we are ever setting an invalid value, this can save
some of us quite some time in the future, since failing to fall in the
range makes the whole pipeline become rejected.
This is in part a workaround for an issue in Qualcomm drivers where the
range for alpha is 0-UINT8_MAX (255). We were setting a value too big
and this would make the whole pipeline fail.
Instead set the top of the property range which is what we were doing
after all, resulting in more explicit code to what we were trying to
achieve.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Deleted windows have frameId zero, which makes Xorg stack other windows
below the bottom-most window instead of the correct one. To avoid that,
filter out deleted windows in Workspace::propagateWindows.
BUG: 478556
There were two problems preventing it from working:
1. The placement tracker didn't handle them correctly; now it sets the custom tile mode
after moving the window to its location
2. The window code used `output()` instead of `moveResizeOutput()`, which means when KWin
just moved the window to a different screen and immediately changes the tile mode
afterwards, it would tile the window on the wrong output
There were two problems:
1. Workspace interacted with the tile mode of windows before inhibiting
the placement tracker, so the wrong window state was stored in the placement
tracker
2. Window::setQuickTileMode is unintuitive and has some undesired side effects,
meant to handle quick tiling with keyboard shortcuts and by dragging the
window with a mouse specifically. This commit just works around that by
un-setting the tile mode first
BUG: 461886
If the X11 socket directory has wrong permissions, XwaylandSocket will
refuse to create sockets. Crashing in that case is undesired, just continue
executing without X.
It seems that, on some systems (such as on mine), 1s is not long enough
for a spurious disconnect and reconnect to happen. 2s seems enough,
however, while still likely not being long enough to cause user
confusion.
BUG: 480026
Process the geometry update as usual but just avoid confuguring the x
windows. It simplifies the implementation of the move resize function
and makes it more refactorable.
GeometryUpdatesBlocker is unnecessary. One could just compute the
final geometry on a side and then issue one moveResize() rather than
call move(); resize(); moveResize() and so on in a sequence. The
advantage of the former approach over the latter is that the code
can be a bit more straightforward.
When a window is closed, its geometry should not change, so the geometry
updates blockers are not needed. There's also no code that could potentially
change the geometry in destroyWindow() or releaseWindow().
Drm planes aren't specialized enough to need completely separate code paths to
handle them, and having one class for all layers makes it easier to add support
for overlay planes
We have a bunch of logic in there that is effectively no-op if the
values don't change. We might as well skip it altogether and save some
code from being run to do nothing.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
While these geometry updates blockers are used in functions that can
call moveResize() several times in a row, it's not critical.
On the other hand, by removing these blockers, no other core code is
going to rely on GeometryUpdatesBlocker, which opens us the future
opportunitinies to drop it and make geometry manipulation code simpler.
Instead of the active screen being purely defined by the mouse position,
or purely defined by the active window and keyboard shortcuts, this changes
it to make the active screen all about the last user interaction. This should
work for most workflows without needing a setting to choose between two flawed
approaches.
BUG: 482865
BUG: 484902
BUG: 484902
There's a bunch of differences between them, like direct scanout, adaptive sync, content type
and the actually painted output in the Wayland session but not on Xorg, so keeping them in one
method doesn't really make sense
This simplifies how the stream resolution is updated and removes a couple
more of failure points. This also appears to fix window screencasts freezing
in obs when those windows are resized.
