We don't need an intermediate widget class here, we can set up the UI directly, like it's done in several effect KCMs already
Not only does this simplify the code, it also fixes crashes due to broken ownership
BUG: 477020
Effect::initConfig() definition can't be moved to effect.h because
it's going to create a cyclic dependency. On the other hand, the real
benefit of initConfig() is doubtful. It's a shortcut for calling
Config::instance(effects->config()), which is small amount of code.
If there's a supported mechanism to handle the format, announce them as
supported.
If there are modifiers supported by the graphics card (even though as
external only), offer them as well.
Otherwise the animation feels wrong while activating with a gesture.
Now when a 1:1 gesture is ongoing, then the Overview effect will stop
animating the overviewVal/gridVal values. I implemented this by porting
to states, giving 1:1 gestures their own states, and only animating the
change between states.
BUG: 476536
After merging libkwineffects and libkwin, EffectsHandler and EffectWindow
have effectively become redundant. On the other hand, Effect and the
associated factory code is still relevant. In order to split relevant and
"legacy" code, this change extracts the Effect class in its own header.
It's also a good idea to split kwineffects.h header because it's quite
huge...
This leaks to other processes that are started by KWin.
The QPA sets ThreadedOpenGL capability to false which suffices
to use the basic render loop with OpenGL.
Effects can hold references to closed windows, which can cause problems
after the workspace is destroyed.
This change makes ApplicationX11 unload effects before destroying the
Workspace and the Compositor similar to how it's done in main_wayland.
BUG: 475511
It doesn't look wrong anymore, presumably what caused it to look wrong before
was just a bug. Blending in sRGB or PQ is still technically wrong, but it
looks okay, and that's an acceptable tradeoff to make in order to get the
responsiveness and power usage improvements the hardware cursor offers
This 1. is more familiar terminology as on other platforms (Gnome, Android); 2. avoids confusion with a planned future day/night light/dark color scheme switcher.
They cause stutters and reduced frame rates on some Intel laptops because the
buffers don't become readable in time, so disable the checks until that's fixed
on the driver side. For debugging purposes, the environment variable
KWIN_DRM_DISABLE_BUFFER_READABILITY_CHECKS can be used to override the default
behavior.
BUG: 476860
this improves the out of the box behavior which has regressed a bit over
time. since we default to kcfg_ActiveMouseScreen=true the active screen
by default follows the pointer. during early startup we position the
pointer on a Placeholder output, this output does eventually get
replaced by the real output(s). because of the update logic we'd
re-position the pointer on the closest real output, but that isn't
necessarily the intended primary output.
e.g. consider an eDP + HDMI setup depending on the geometries involved
the cursor may end up on the HDMI screen by default rather than the eDP
resulting in plasma-welcome opening on the HDMI output.
to mitigate this problem we now track whether the last output was a
placeholder and if so we instead try to position the pointer on the
current primary output
