It doesn't test anything useful. It's hard to make it test useful things
too due to needing to change the system time. Linking with it also
breaks the encapsulation and it won't work when using MODULE library.
* Allow to do quick tiling to custom tile geometries, windows will be snapped to tiles when dragged with the shift modifier pressed.
* Tile geometries are screen specific.
* The global shortcut Meta+T will trigger a fullscreen configuration ui as a QML effect for the tiles which allows to add, remove and resize tiles
* UI and behavior is a bit similar to the Windows Fancy Zones addon: https://docs.microsoft.com/en-us/windows/powertoys/fancyzones
* Its main scope is to help the workflow with very big monitors, especially ultra wide ones, where most application don't make sense maximized to the full screen (eventually also support games to be full screened to a given tile instead of the whole screen)
* it should get also some bindings for scripting, as its ain goal is not to replicate other popular tiling window managers, but should give the popular kwin tiling scripts to have a more robust infrastructure
* it will eventually get support for a set of predefined layouts, but this is for a second phase
BUG: 438788
The entire approach behind that test is wrong. Even slight changes in
one pixel can make the test fail. There's no human-friendly way to
determine what the difference between reference and actual frames are.
The reference frame is generated in code rather than from an image on
the disk, which makes the tests even more error-prone.
The test is flaky too and constantly blocks merging patch submissions.
We need a different way to test rendering results, not what
testSceneQPainter currently does. Normally, I would say that we need
to add such an infrastructure before dropping the test, but it makes the
merging process so inconvenient and the test doesn't really bring any
value, it tests really basic cases which are noticeable right away after
launching kwin.
Client-side wrappers for input-method-unstable-v1 fail to build because
wl_keyboard_interface is referenced in the header file generated by
wayland-scanner.
Unfortunately, qt6_generate_wayland_protocol_client_sources() forces
--include-core-only argument, this is addressed in Qt 6.4.1, but in
meanwhile let's ship a copy of Qt6WaylandClientMacros.cmake file until
the required Qt version is out.
When we do more color management stuff we'll need it in more places,
making it a hard requirement reduces the amount of needed ifdefs and
should make adding color management features a little simpler.
[6/6] Make autotests create fake input devices
This test was the only one where input() could return a nullptr. With
this test removed, autotests can now expect input() to always return a
sane valid value and are therefor simpler to write.
That test belongs in kwayland-server anyway and kwayland-server's test
suite already tests that starting without XDG_RUNTIME_DIR is a no-no
thing
The output management test checks the implementation of output
management capabilities in the virtual backend, which is not helpful.
This change replaces it with a more useful test that verifies how
windows are placed after an output change.
Ever since the effects were changed to static, each test of the
integration tests includes all the effects. The result of this is that
when doing a debug build each test is now 60MiB or more. With the amount
of tests, this results in ~8 GiB of diskspace used just for KWin's
binary output directory, which is rather excessive.
Since the tests all share a common framework library, we can change that
library to a shared library and that way avoid linking all the effects
into each test.
Most of this is shuffling around some link libraries in the integration
test CMakeLists, however, I needed to export the Xwayland class as it is
used by one of the tests but wasn't exported.
The main motivation behind this change is to prepare kwin for importing
kwayland-server code in libkwin.
As is, builtin effects are linked with libkwin. Some builtin effects
have wayland specific code. If we move wayland stuff in libkwin, there's
going to be a circular dependency between kwin4_effect_builtins and
libkwin targets.
This change intends to break that dependency by linking builtin effects
to kwin executable.
The main issue with that is that EffectLoader would need to discover the
effects indirectly. QStaticPlugin is used for that purpose.
Besides breaking the cyclic dependency, it makes builtin effects use the
same plugin infrastructure in libkwineffects that external effects use.
Metadata in src/effects/effect_builtins.cpp was converted in a list of
python dictionaries, which was fed to a python script that generated
main.cpp and metadata.json files.
Due to the screen edges test not being an integration test, it's very
hard to change output related code in libkwin. screens.cpp needs to have
a few ifdefs to successfully compile.
This change rewrites the screen edges test as an integration test in
order to allow us using other components of kwin in screens.cpp and
screenedge.cpp without ifdef guards.
It's not a one-to-one port.
Drop-shadows with the software render backend impact performance quite
significantly. It also makes it easier to prepare render backends for the
item based design.
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.
At the moment, the Screens class is convoluted with ifdefs because of
MockScreens.
The goal of this change is to reduce the number of usages of the
MockScreens class so it is possible to get rid of the ifdefs.
This change introduces a new component - ColorManager that is
responsible for color management stuff.
At the moment, it's very naive. It is useful only for updating gamma
ramps. But in the future, it will be extended with more CMS-related
features.
The ColorManager depends on lcms2 library. This is an optional
dependency. If lcms2 is not installed, the color manager won't be built.
This also fixes the issue where colord and nightcolor overwrite each
other's gamma ramps. With this change, the ColorManager will resolve the
conflict between two.
Night Color adjusts the color temperature based on the current time in
your location. It's not a generic color correction module per se.
We need a central component that can be used by both night color and
colord integration to tweak gamma ramps and which will be able to
resolve conflicts between the two. The Night Color manager cannot be
such a thing because of its very specific usecase.
This change converts Night Color into a plugin to prepare some space for
such a component.
The tricky part is that the dbus api of Night Color has "ColorCorrect"
in its name. I'm afraid we cannot do that much about it without breaking
API compatibility.
Without the KWindowSystem integration plugin, Wayland experience will be
negatively affected because windows created by kwin itself won't behave
as desired. Therefore it makes little sense to load this plugin at runtime.
On wayland, we know we're always going to load our internal QPA. Instead
of shipping a plugin and loading it dynamically we can use Qt static
plugins.
This should result in slightly faster load times, but also reduce the
number of moving pieces for kwin.
This also prevents anyone outside kwin loading our QPA which wouldn't
have made any sense and just crashed.
After splitting out the server part of KWayland into a separate repo,
all non-core protocol wrappers in KWayland::Client had become obsolete
and using them in new projects is highly discouraged.
The layer-shell protocol allows wayland clients to create surfaces that
can be used for building desktop environment components such as panels,
notifications, etc.
The support for the plasma-shell protocol will be dropped once plasma in
all its entirety is ported to the layer-shell protocol.
in XdgSurfaceClient setFrameGeometry is async,
so we can't rely on it having the final value immediately.
make setVirtualKeyboardGeometry a virtual.
in the implementation on setVirtualKeyboardGeometry
use requestedFrameGeometry() instead of frameGeometry()
If the Xwayland process has crashed due to some bug, the user should
still be able to start applications in Xwayland mode. There is no reason
to restart the whole session just to be able to launch some application
that doesn't have native support for Wayland.
