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.
Without this patch the following warning is issued:
Could not convert argument 1 at
onTriggered@file:///usr/share/kpackage/kcms/kcm_kwin_effects/contents/ui/Effect.qml:129
onClicked@file:///usr/lib/qml/org/kde/kirigami.2/templates/SwipeListItem.qml:485
Passing incompatible arguments to C++ functions from JavaScript is dangerous and deprecated.
This will throw a JavaScript TypeError in future releases of Qt!
`bottomLeft()` is affected by the same issue as anything else using
bottom, that is, it is off by 1. So instead use top() + height() for the
bottom edge.
This behavior was added in order to fix a crash reported in bug report
442990. However, the analysis was not 100% correct, kwin failed to
create a placeholder because the relevant check was incorrect. The drm
backend was checking the list of all connected outputs rather than the
list with enabled outputs to decide whether to create a placeholder output.
As a safety measure the proposed behavior makes sense, however the drm
backend is not the right layer to implement it. If the last enabled
output is disconnected, kscreen should view it as a new output
setup and re-enable outputs in order to ask user what desired output
configuration should be.
This port the remaining bits in EffectsHandler from Screens. It does
make sense to deprecate or remove workspace geometry bits in
libkwineffects as the interpretation of the workspace layout is very
effect-specific, e.g. as in the slide effect.
Without this, the rowsChanged signal wasn't emitting at startup, so the
binding `highlight: kcm.desktopsModel.rows !== 2` didn't work correctly.
FIXED-IN: 5.24.7 5.25.3 5.26
The guessed repaint region is not optimal on wayland. Second, if it's a
new output, it's expected that there will be already a scene repaint
that covers all items on the given output so items don't need to provide
redundant repaint region.
The kernel doesn't disable connector objects that represent physical ports
when the output gets removed. If KWin tries to change the output configuration
without explicitly disabling the connector, atomic commits can fail.
