Due to the wrong buffer format, the function failed with
GL_INVALID_OPERATION error, which was silently ignored by the effect.
It resulted in the constant phantom color being returned over and over
again.
Co-Authored-By: David Edmundson <kde@davidedmundson.co.uk>
BUG: 454974
FIXED-IN: 5.24.7, 5.25.4, 5.26
Currently, defining shortcuts in useractions.cpp is done using one of
six macros, some of which allow the name that ends up as the key in
the config file to be autogenerated from an untranslated form of the
user-facing text.
Whenever a shortcut using one of these macros is renamed, the key in the
config file changes too, so users lose any custom shortcuts they had
assigned.
To avoid this, developers need to know that they have to switch to the
relevant macro that allows the name and description to be defined
separately, remember to do so, and manually set a name that matches the
old user-facing text. This can be forgotten, is not obvious to new
developers, and is a subtle source of user-facing bugs.
In addition the macros are largely unnecessary, as they are wrappers
around a custom function. We can just call the custom function
ourselves.
This commit ports away from the macros and calls the initShortcut()
instead, which resolves both issues.
cc @davidre
The original intention behind creating plugins before the workspace was
to handle the case where kwin_wayland may need to wait until outputs are
available. However, since things have changed a lot in that regard,
plugins can be loaded after the workspace now.
The main benefit behind this is that plugins can be simpler, they won't
need to track when the workspace is created.
On X11, plugins are already loaded after the workspace is instantiated.
This change adjusts the window management abstractions in kwin for the
drm backend providing more than just "desktop" outputs.
Besides that, it has other potential benefits - for example, the
Workspace could start managing allocation of the placeholder output by
itself, thus leading to some simplifications in the drm backend. Another
is that it lets us move wayland code from the drm backend.
The main motivation behind this change is to make the drm backend
multi-purpose. That's it, to make it suitable for implementing all kinds
of compositors. At the moment, there's an artificial split between
"desktop" and "non-desktop" outputs, i.e. VR headsets, which stands in
the way of that and moving the remaining wayland code out of the drm
backend for better layering and architecture.
This way we make sure that we don't explode if for some reason the
surface is destroyed (e.g. it's closed).
This will make it work exactly like the other references to
SurfaceInterface.
BUG: 456817
An effect that implements the "identify" functionality of
the screen configuration kcm. It displays a label on each
screen that identifies the screen.
Doing this as a kwin effect allows to correctly handle
the case when outputs are mirrored (on wayland) compared to
absolute positioning of windows which end up on top of each other.
This allows us to get more information about the outputs like vendor
and model and for example provide them to effects which might find
the extra info useful.
KWin requires surfacesless contexts, so this setSurface() is not needed.
This ensures that makeCurrent() won't make the opengl context current
against a surface that belongs to a removed output.
KWin requires surfacesless contexts, so this setSurface() is not needed.
This ensures that makeCurrent() won't make the opengl context current
against a surface that belongs to a removed output.
The main reason to drop multi-head support is that it has been simply
unmaintained for many many years. When implementing a feature, we don't
even bother checking if multi-head is broken, KCMs don't handle
multihead, window management features are written for Xinerama. KWin
is optimized for Xinerama-like operation mode in general, which is
provided out of the box.
If you use multihead for esoteric gpu stuff, consider using kwin_wayland!
If a DesktopView doesn't handle a keyboard navigation event it
propagates to main which then focusses the next desktop view and the
relevant window.
Empty desktops can also be selected.
BUG: 456068
In WindowHeap we currently always accept the keyboard event regardless
of whether the event was handled.
This will allow the event to propagate to other handlers
In WindowHeap we currently always accept the keyboard event regardless
of whether the event was handled.
This will allow the event to propagate to other handlers
Most xwayland clients don't know their desktop file name, so use the
StartupWMClass field in their desktop files as means to inferring their
desktop file name.
BUG: 455265
l10n daemon script