As KWin measures render times properly now, these settings and estimations
should no longer be necessary, so this commit replaces them with one hardcoded
algorithm that should prevent most dropped frames and reduce latency
Amends 4d2c9f5d88.
Prior to 4d2c9f5d88, the Compositor used
to force the Options to reload settings when starting compositing.
Unfortunately it was overlooked that Options::animationTimeFactor() can
return an old value when the Options::animationSpeedChanged() signal is
emitted. This change addresses that.
Config loading is split in two groups: loading compositing config and
loading the rest. They are loaded separately at different times. Some
options are loaded in the Options constructor, some are loaded when compositing
starts, some are loaded when the Workspace is created. It's not easy to
keep track of what loads what and when.
This change simplifies option handling by loading all options in bulk
and decouples Options from OutputBackend and GLPlatform to ensure that
it can safely load options before kwin is fully operational.
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
It's somewhat popular for voice communication applications to support
Push-to-Talk. This means that the process itself expects to get all of
the system input. This behaviour albeit sound does not work on Wayland
systems.
This commit adds an option to let legacy X11 applications that assume
they will be getting all information to do so until these apps are
properly ported to the XDP GlobalShortcuts.
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.
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 .clang-format file is based on the one in ECM except the following
style options:
- AlwaysBreakBeforeMultilineStrings
- BinPackArguments
- BinPackParameters
- ColumnLimit
- BreakBeforeBraces
- KeepEmptyLinesAtTheStartOfBlocks
This ensures that we get a warning if the config header is not included
instead of compiling the code as if it was disabled. Interestingly, some
checks already used #if KWIN_BUILD_*, so those were generating -Wundef
warnings when the feature is disabled. Commit 886173cab assumed that all
those features were already 01, so this unbreaks the build if any of the
features is disabled.
Fixes: 886173cab ("Reduce ifdefs in Workspace::supportInformation()")
It's not practical, regular users don't care about window geometry. One
could argue that it can be useful for creating window rules, but window
rules kcm pulls relevant properties from kwin.
If needed, one can reimplement this feature as a QtQuick script that creates
an overlay window positioned above the window that is being interactively
moved or resized.
This change merges the two OpenGL backends into one making the current
default of GLCore the overall default. It becomes the first context to
try to create. If it fails, it will automatically fall back to the
(previous) OpenGL 2 backend.
Reasoning: the differentiation of OpenGL 2 and 3 is a very technical one
and hard to understand for users. It is not obvious which one is better
or should be used. This results in many user discussions like "Which
backend to use?"
Back when the OpenGL 3 backend was introduced the dedicated feature made
sense. It was a new code base using new driver features. Nowadays the
code base in KWin is robust and mature and so are the drivers. A driver
advertising support for OpenGL 3 will support OpenGL 3. We don't have to
plan for driver breakage in this area any more.
Also our code evolved through the context attribute builder which gives
us the possibility to more easily fall back in case we cannot create the
context. Thus the need to select the backend is not so important as it
used to be when the feature got introduced.
If a user still wants to force OpenGL2, it is still possible by setting
the appropriate environment variables like MESA_GL_VERSION_OVERRIDE.
This change brings the improvement that the backend selection is now
completely removed from the compositing KCM.
Active output is a window management concept. It indicates what output
new windows have to be placed on if they have no output hint. So
Workspace seems to be a better place for it than the Screens class, which
is obsolete.
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.
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
