Some users prefer this over the existing options. It e.g. allows to open
a bunch of links and only then switch to the browser on a different desktop
BUG: 464283
The widget was renamed a while back, but the KCM still used the old
term to refer to it when letting the user choose the visual effect that
it shows the user. Let's change that.
BUG: 463087
FIXED-IN: 5.27
- 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
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
The Xrender backend was added at the time when OpenGL drivers were not
particularly stable. Nowadays though, it's a totally different situation.
The OpenGL render backend has been the default one for many years. It's
quite stable, and it allows implementing many advanced features that
other render backends don't.
Many features are not tested with it during the development cycle; the
only time when it is noticed is when changes in other parts of kwin break
the build in the xrender backend. Effectively, the xrender backend is
unmaintained nowadays.
Given that the xrender backend is effectively unmaintained and our focus
being shifted towards wayland, this change drops the xrender backend in
favor of the opengl backend.
Besides being de-facto unmaintained, another issue is that QtQuick does
not support and most likely will never support the Xrender API. This
poses a problem as we want thumbnail items to be natively integrated in
the qtquick scene graph.
Summary: Alt + Left Click to move windows has a tendency to conflict with creative workflow apps. While Alt can be changed to Meta in KWin's settings, Alt + Left Click shortcuts often cannot be customized in apps. Rather than making every user who runs into this problem change their settings, we should change our default settings to improve KWin's default usability. The fact that Alt + Left Click to move windows is older does not matter. We are trying to use Meta for global/shell shortcuts anyway.
BUG: 399375
Test Plan: The relevant parts of the relevant tests pass. kwin-testInternalWindow fails, but for unrelated reasons that have something to do with XWayland.
Summary:
The "Candy" category suffers from some problems:
- It does not need to exist; everything in it is purely appearance-related and could live in the existing "Appearance" category
- The name is inappropriate; "Eye Candy" would be better, but changing it to this has proven controversial in the past
Let's just remove the category and move everything in it into the "Appearance" category.
Test Plan:
Apply and compile
Open Desktop Effects KCM
See that the "Candy" category is no more and the "Appearance" category has more stuff in it
Reviewers: #kwin, #vdg, zzag, abetts
Reviewed By: #kwin, #vdg, zzag, abetts
Subscribers: abetts, zzag, kwin, kde-doc-english, GB_2
Tags: #kwin, #documentation
Differential Revision: https://phabricator.kde.org/D27658
Summary:
Hopefully, the new document makes it clear when one can use QRect::right()
and QRect::bottom().
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27060
Summary:
Right now a few of the window placement modes suffer one or more of the following problems:
- Inconsistency between the text shown in the Window Behavior and Window Rules KCMs
- Title does not indicate what it does
- Awkward wording
- Lack of unity in grammatical mood between the different modes
This patch fixes these issues by improving the strings and standardizing on the descriptive mood:
- Smart -> Minimal Overlapping
- Maximizing -> Maximized
- Cascade -> Cascaded
- Zero-Cornered -> In Top-Left Corner
Strings are also unified between the window behavior and window rules KCMs, and docbooks are adjusted accordingly.
Test Plan:
{F7279685, size=full}
{F7279694, size=full}
Reviewers: #kwin, #vdg, ndavis, filipf, zzag, romangg
Reviewed By: #kwin, #vdg, ndavis, filipf, romangg
Subscribers: gladhorn, alexeymin, IlyaBizyaev, broulik, hein, hpereiradacosta, GB_2, alexde, davidedmundson, romangg, cfeck, filipf, zzag, ndavis, kwin, kde-doc-english
Tags: #kwin, #documentation
Differential Revision: https://phabricator.kde.org/D23415
Summary:
This has been commented out since 2014, I doubt it will come back.
This is a big amount of code, maintenance will be easier without it.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: romangg, graesslin, kwin
Tags: #kwin, #documentation
Differential Revision: https://phabricator.kde.org/D23069
Summary:
All other KCMs have their {nav Get New [things]...} buttons in the bottom-right corner. This patch adjusts KWin's KCMs to adopt the same convention there too.
With this patch, all KCMs will have their GHNS buttons in the same location.
Closes T9954
Test Plan:
{F6375278}
{F6375277}
{F6375276}
{F6375275}
Reviewers: #kwin, #vdg, zzag
Reviewed By: #kwin, zzag
Subscribers: Codezela, kwin, kde-doc-english
Tags: #kwin, #documentation
Maniphest Tasks: T9954
Differential Revision: https://phabricator.kde.org/D16537
Ismael Asensio