Adds whitespace between documented members of the header file.
Currently the members are all bunched together, making it difficult to
read as one flows directly into the next. This change adds a newline
between each member, making it easier to read.
Allow the creation of screen edges bordering two screens. This allows
panels in auto-hide/dodge-windows mode to work when the panel is
positioned between two edges.
Don't change the X11 behavior since edge barrier is not supported on
X11, without which it is virtually impossible to exactly position the
cursor on the pixel to activate the edge.
BUG: 351175
Allow users to configure a virtual edge barrier between screens.
The pointer will only cross over to the other screen after the distance
travelled surpasses edgeBarrier.
Reduce the speed during interactive moveresize, at edges that trigger,
and at the corner.
Only supports wayland. Doesn't have X11 support since it is far too
complicated there.
BUG: 416570
BUG: 451744
A target mobile DPI of 135 is rather low and results in excessively
large scale factors, so everything is too big.. Let's raise it a
little bit to improve the default level of information density on
these devices that are designed to be held close to the face.
This has the effect of changing the calculated default scale factor for
the following devices:
| Device | Device DPI | Old scale factor | New scale factor |
| ---------- | ---------- | ---------------- | ---------------- |
| Steam Deck | 204 | 1.5 | 1.25 |
| PinePhone | 268 | 2.0 | 1.75 |
| OnePlus | 388 | 3.0 | 2.5 |
Devices are taken from the autotest data found at
https://invent.kde.org/plasma/kscreen/-/blob/master/tests/kded/configs/AutogeneratedMobileScreenScales.json
The autohidden panels "blink" because this effect animates their opacity.
The dock windows are animated because, as the comment says, the old effect
animated almost every window.
Conceptually, animating docks doesn't align with the purpose of this effect.
Wayland has a design philosophy of prohibiting keyloggers, which is
sane. However X11 did not, and a lot of X11 apps were developed with the
expectation of being able to sniff keyboard events to handle global
shortcuts. When such apps are run in a Wayland session under XWayland,
these features break.
Historically we have prohibited this in the name of security. In Plasma
5.27, we gave users a KCM they can use to choose their preferred balance
of security and unbreaking XWayland apps with global shortcuts. But we
still defaulted to total 100% security, at the expense of breaking these
apps by default.
However today we have a compromise that unbreaks them 99% of the time
while not meaningfully reducing security: we can have KWin only prohibit
XWayland apps from reading alphanumeric key events that don't have a
modifier key pressed at the same time. This still prevents those apps
from acting as keyloggers and reading your password or all the text you
type, but does allow those apps that have a legitimate need to read key
events for global shortcuts do so, because global shortcuts will involve
modifier keys being held down.
Due to the way the security modes work, making this change will also
allow XWayland apps to read non-alphanumeric keystrokes without any
modifiers being held down, but that's also fine for security since you
can't use any of those keys to type text or passwords.
NET::OnAllDesktops is a special desktop number (-1), desktopForX11Id will not return a desktop for it
When all desktops are requested pass an empty desktop list, the following code will handle it appropriately
BUG: 482670
We need to re-arrange layer shell surfaces, compute new struts and adjust
the windows in a single step.
Workspace::updateClientArea() is the best candidate for that, so this change
repurposes that function from computing work areas to a generic relayouting
function.
CCBUG: 482361
When the output layout changes, the Workspace is going to update the
struts and then go through every window and see whether it should be
moved or resized.
On the other hand, the layer shell windows react to output changes on
a timer. Furthermore, it's not synchronized with the workspace rearranging
the managed windows. It means that when Workspace::desktopResized() runs,
the panel struts can be slightly outdated, i.e.
- An output layout change occurs
- Workspace::desktopResized() is called but the struts can be wrong
- some time later, LayerShellV1Integration::rearrange is called, it
fixes layer shell window geometries and struts
- after the layer shell integration has finished rearranging the
layer shell windows, it calls Workspace::desktopResized(), but the
damage had already been caused
With the proposed change, the Workspace and the LayerShellV1Integration
will rearrange the windows in sync.
CCBUG: 482361
The behavior between direct scanout and normal presentation being different is an
implementation detail of DrmPipeline, the output layers shouldn't need to care
Multi monitor setups with 4K screens are not uncommon and one of the
annoyances associated with such setups is that you lose the track
of the cursor sometimes. It's natural to shake the cursor in such
occasions.
This change enables the shake cursor effect to improve the desktop
experience. One potential risk associated with doing so is that the cursor
can be magnified in some undesired situations. It is true. But we took a
great precaution of that and added some heuristics to avoid triggering the
effect in such cases given all the data we have available.
Only store one history item for movement in the same direction.
With this optimization I measure m_history.size() <= 15 for all kinds of
movements, including back and forth, and circular.
