Since ScreenEdge no longer uses physicalDpiX() and physicalDpiY() from
the QPaintDevice class in favor of our own helpers, we need to ensure
that the X11 platform provides valid output physical dimensions.
BUG: 422816
FIXED-IN: 5.19.2
Every `AbstractItemDelegate` was instantiating a `Kirigami.ActionToolBar`,
which is a very expensive component, rising CPU usage specially on long lists.
Use `Kirigami.SwipeListItem` instead, as is seems the proper component.
BUG: 421537
The first time the list in `Add properties` is shown, the position of the first
delegate is miscalculated as (0, 0) and gets hidden behind the section header.
It only repositions when the delegate is destroyed and re-created, for example, when
setting and deleting a filter text. (https://bugs.kde.org/show_bug.cgi?id=422289)
This works-around it by delaying the `overlayModel` filtering until the list is first
shown, which makes the delegate position correctly.
BUG: 421583
FIXED-IN: 5.19
The recommended way to get all EGL extension defines is to include
EGL/eglext.h. EGL/eglmesaext.h is a private header that compositors
should not use.
BUG: 422131
Since the port to KConfigXT, the placement setting in `kwinrulesrc` now stores the enum value instead of a string equivalent.
The strings and enum values are taken from `placement.h/.cpp`
This was suggested by @zzag in https://phabricator.kde.org/D29790
We don't need to bind disabled outputs to surfaces that overlaps them.
This prevents error down the line and warnings about ignoring surface.enter events with Qt.
BUG: 419749
Summary:
Present windows works as follows:
- It moves all windows about until nothing is overlapping with any
other window.
- This doesn't resize anything so ultimately we end up with a new
co-ordinate space that's bigger than the screen depending on the amount
of overlap.
- We then render this whole view transformed to the screen
The rectangle "bounds" is in overviewpixels, with "scale" being the
ratio to convert to screen pixels.
When adjusting the new bounds there's an attempt to centre align things.
As bounds is in "overviewpixels" we multiply references to the previous
bounds by scale, and divide everything through at the end. bounds.x/y
were missed.
This is mostly unoticable except on massive super-ultra-wide monitors
which will otherwise have a tendency to shift to the left.
Test Plan:
Kai created a whole new test framework for this code that copy pasted
this algorithm then showed mock windows as rectangles
Reviewers: #kwin, apol, broulik, zzag
Reviewed By: #kwin, apol, broulik, zzag
Subscribers: zzag, apol, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29705
Currently, the spinners used to edit position and size rules have an upper
limit of 4098, which may be not enough for wide/hdpi/mutiple screens.
The property itself has no such limit in the `.kcfg` schema
This is just an issue with the editor.
BUG: 421892
FIXED-IN: 5.19
Even though the frame geometry and the client geometry have a connection
between themselves, it doesn't mean that the frame geometry will change
if the client geometry has changed and vice versa. For example, it can be
the case when the border size changes. The frame geometry won't change,
but the client geometry will.
In general, similar to the frameGeometryChanged signal, we need another
signal that is emitted when the client geometry has been changed that
can be used then in DecoratedClientImpl.
Unfortunately, 5.19 release is around the corner and I would prefer not
to do any geometry-related changes in order to avoid introducing new
regressions.
In order to fix the propagation of the client size to decorations, this
change ports DecoratedClientImpl from frameGeometryChanged to a signal
that is emitted whenever geometry of any kind has been changed.
BUG: 419080
FIXED-IN: 5.19.0
In previous code we used to update/show cursor even when the pointer
device was present, e.g mobile device. Guard it behind the cursor
enabled check.
BUG: 418977
FIXED-IN: 5.19.0
In order to generate window quads for a window, the scene needs a valid
WindowPixmap tree. If it's time to render the window, the scene will
build window quads for the contents, the server-side window decoration,
the drop-shadow and cache the resulting window quads. With this way of
generating window quads, we need the window pixmap tree to be valid,
or else no contents window quads will be generated.
While the window pixmap tree is guaranteed to be valid at the time of
generation of window quads for Wayland and X11 clients, this is not the
case for Xwayland clients.
When an Xwayland client is created, some time may pass between the
moment it's been created and the moment when a regular wayland surface
has been associated with the xwayland window. If the compositor decides
to render the Xwayland client in that short period of time, the window
quads cache won't have window quads cache.
In order to work around the weird asynchronous behavior of Xwayland
clients, this change makes the scene discard the window quad cache when
a new window pixmap has been created. This will ensure that the current
window quads are always in sync with the current window pixmap tree.
The list of virtual desktops is retrieved using a DBus method, instead of
`KWindowSystem`, to make it work both in Wayland (as well as X11).
FIXED-IN: 5.20
BUG: 416165
Summary:
Since the port to KConfigXT, the setting "placement" is stored using the enum value, instead of a string equivalent.
This updates the kcm model to be able to communicate this property with the config schema.
BUG: 421586
FIXED-IN: 5.19.0
Test Plan:
- In a rule set the "Initial Placement" property
- The value is stored in `~/.config/kwinrulesrc`
- Close/reopen the kcm. The placement value is correctly loaded.
Reviewers: #kwin, #plasma, zzag
Reviewed By: #kwin, #plasma, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29790
Summary:
Use `QSize`/`QPoint` to handle and store coordinate values (size and position)
Previously, the rules model stored the "coordinate" type properties as a
`QString` with format `x, y`.
This fails when setting the properties to the config schema, as it requires
a proper `QPoint` or `QSize` value, specially the latter which can't be
convert from such a string.
BUG: 421055
FIXED-IN: 5.19.0
Test Plan:
- Add a new rule and set its position and size properties
- Hitting apply stores the right values in `~\.config\kwinrulesrc`
- Close the kcm and reopen, the values are loaded
- Property detection still works for size and position
Please note that there is a pre-existing bug of some position/sizes not being
applied to the windows in some cases, when using `Apply Initially`.
Better try using the `Force` policy.
Reviewers: ngraham, #kwin, #plasma, zzag
Reviewed By: #kwin, #plasma, zzag
Subscribers: zzag, ltoscano, yurchor, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29764
Summary:
e.g. "Vertically maximize" is more natural and expressive than "Maximize (vertical only)"
See D29671#inline-169882.
Test Plan: New strings appear in the KCM
Reviewers: zzag, #vdg, #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29729
Summary:
Similar to regular cursors a drag surface can have a scale.
The buffer "rect" should be in logical pixels at which point QPainter
will automatically handle everything.
CCBUG: 421395
Reviewers: #kwin, zzag, apol
Reviewed By: #kwin, zzag, apol
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29672
Summary:
Currently, we use icons to display possible maximize button actions. The
problem with those icons is that they are confusing even for me, a person
who knows kwin in and out. The size_all icon implies that if you click the
maximize button, you'll be able to move the window around. Same goes with
the size_ver and size_hor icons, they indicate that user will start
resizing the window in the vertical and horizontal direction, respectively.
Test Plan:
Before
{F8312394}
After
{F8312395}
Reviewers: #kwin, #vdg, ndavis
Reviewed By: #vdg, ndavis
Subscribers: ngraham, ndavis, broulik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29671
Summary:
Currently, if one wants to monitor for new X11 and Wayland clients, they
have to listen for two signals. Workspace::clientAdded() is emitted only
for X11 and Xwayland clients, while WaylandServer::shellClientAdded() is
emitted only for xdg-shell clients. Such design doesn't scale well.
As the first towards emitting Workspace::clientAdded() for new Wayland
clients, this change replaces the X11Client parameter in the clientAdded
signal with AbstractClient.
Test Plan: Tests still pass.
Reviewers: #kwin, cblack
Reviewed By: cblack
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29665
