We assume that outputs in kwinApp()->platform()->enabledOutputs() are
stored in the xinerama order. However, this is not the case on Wayland
and it's not going to be changed because it increases the complexity.
This change makes Workspace::xineramaIndexToOutput() use Xinerama
extension API to map a xinerama index to the associated Output object.
With this, Xwayland applications will be able to put on outputs as
expected.
Note that xinerama indices are not cached because
Workspace::xineramaIndexToOutput() is not used in any hot code path. If
that changes, xinerama indices can be cached. The cache must be
invalidated whenever we get screens changed notify event from RANDR.
Currently, we implicitly assume that enabled outputs are stored in the
xinerama order, but with ongoing refactorings, it's easy to break that
assumption. Also, we are not going to change the DRM backend so it
stores enabled outputs in the xinerama order.
This change adds xinerama index conversion helpers in order to reduce
the number of potential regressions with output refactorings.
There was a geometry change that fixed mixing the next and current
geometries. While it did fix issues on wayland, it broke window shading
on x11 because of an obscure resize() call.
That obscure resize() had a side-effect that ensures m_clientGeometry
has the right value so the next time the window is unshaded,
implicitSize() will return a good value.
In order to make window size computation more robust, this change makes
X11Window compute the natural frame size based on cached size in
m_client, which shouldn't change when the window is shaded.
However, given how buggy window shading is and how difficult it is to
make it work right, I think that it's better to deprecate window shading
and remove it in some future release.
BUG: 450582
Currently, the highlight effect is not very visible because it only
barely peeks out of the window thumbnail. We can make it bigger by
making it peek out a little bit more, and also by including the window
title and icon (when visible) within it.
BUG: 454842
This code uses the DEF() macro which silently re-uses an untranslated
version of the string as the ID in the config file. So anytime you
change the text, a new entry will be created in the config flil and
users will lose any custom shortcut mappings.
To avoid this, use the DEF2() macro instead, which allows defining the
ID and the user-facing translated name differently.
We gain nothing with it. XCB setup logic in the Xwayland server has to
be moved to the workspace layer anyway. For example, this move of
responsibilities will be needed to support running more than just one
instance of Xwayland. Architecture-wise, it would be cleaner too.
Unfortunately, it breaks encapsulation of the Application, but this can
be taken care later.
In the desktop grid effect, dragging an empty area of a desktop to
another desktop swaps all windows on the two desktops. This change makes
sure that this matches only windows in the current activity.
Was earlier fixed in
1e0b0c881e
, but the bug was reintroduced by the QML rewrite.
BUG: 386769
Having RollOverDesktops false is more intuitive and "natural" for
new users, who may be disoriented by virtual desktop navigation
wrapping around (especially for small numbers of virtual desktops)
and not find the setting to change it very easily.
Relying on the texture matrix to normalize means we multiply every UV
coordinate with 1/scale, which leads to floating point errors and thus
errors in the UV coordinates. Instead, if we calculate normalized
coordinates directly we avoid floating point error and get proper UV
coordinates.
Longer term the plan is to make all UV coordinates normalized and get
rid of the CoordinateType altogether.
With fractional scaling integer based logical geometry may not match
device pixels. Once we have a floating point base we can fix that. This
also is
important for our X11 scale override, with a scale of 2 we could
get logical sizes with halves.
We already have all input being floating point, this doubles down on it
for all remaining geometry.
- Outputs remain integer to ensure that any screen on the right remains
aligned.
- Placement also remains integer based for now.
- Repainting is untouched as we always expand outwards
(QRectF::toAdjustedRect().
- Decoration is untouched for now
- Rules are integer in the config, but floating in the adjusting/API
This should also be fine.
At some point we'll add a method to snap to the device pixel
grid. Effectively `round(value * dpr) / dpr` though right now things
mostly work.
This also gets rid of a lot of hacks for QRect right and bottom which
are very
confusing.
Parts to watch out in the port are:
QRectF::contains now includes edges
QRectF::right and bottom are now sane so previous hacks have to be
removed
QRectF(QPoint, QPoint) behaves differently for the same reason
QRectF::center too
In test results some adjusted values which are the result of
QRect.center because using QRectF's center should behave the same to the
user.
We need to reset the QML Item on failure or trying to load a
different switcher afterwards will pick a wrong codepath and
also fail.
BUG: 445455
FIXED-IN: 5.25.4
Some legacy drivers either don't accept gbm buffers suitable for cursors,
or don't handle them properly. In order to work around that, always do a
CPU import with legacy and use dumb buffers instead.
BUG: 453860
CCBUG: 456306
The Screens object is created by Workspace on X11. This change makes X11
and Wayland behave more similar. As is, the Screens is a helper for
window management code, don't use it in backends. Note that the X11 backend
already uses the Screens, it needs to be addressed individually.
We don't really care about the window showing up until we're calling
showInputPanel, but since Workspace::windowAdded is triggered for any
window that gets added, the test sometimes fails because count() is 2
instead of 1. To avoid that, only create the spy when it's actually
relevant instead of all the way at the start before any other setup is
done.
We now rely on auto-vectorisation to generate the appropriate SSE or
other instruction set code. We can also assume that takes care of
handling any alignment requirements and thus remove the need for manual
alignment things.
Both GCC and Clang do auto vecrization these days and testing shows that
that actually produces faster code, so dropping the SSE stuff makes
things both simpler and faster.
Xaver Hugl