Summary:
Currently, there are a couple of issues with sizeForClientSize(). First
of all, we have a method called clientSizeToFrameSize() which does similar
thing except applying geometry constraints and checking window rules. The
other issue is that sizeForClientSize() is doing a bit too much, it checks
window rules, it applies a bunch of geometry constrains. Sometimes it
does not perform conversion between client sizes and frame sizes!
This change attempts to address those issues by replacing sizeForClientSize
with two similar methods and changing semantics of some methods of the
X11Client class.
The most significant difference between sizeForClientSize() and the new
methods is that neither constrainClientSize() nor constrainFrameSize()
check window rules. This is up to users of those methods. In many places,
we don't have to check window rules because we check isResizable(),
which returns false if the frame size is enforced by a window rule.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26828
Summary:
Currently we have two signals that are emitted when the Toplevel's geometry
changes - geometryShapeChanged() and geometryChanged(). The former signal
is used primarily to invalidate cached window quads and the latter is
sort of emitted when the frame geometry changes. But it's not that easy. We
have a bunch of connects that link those signals together...
The worst part about all of this is that the window quads cache gets
invalidated every time a geometry update occurs, for example when user
moves a window around on the screen.
This change introduces a new signal and deprecates the existing geometryChanged
signal. frameGeometryChanged is similar to geometryChanged except that it is
emitted when an _actual_ geometry change has occurred.
We do still emit geometryShapeChanged signal. However, in long term, we
need to get rid of this signal or come up with something that makes sense
and doesn't require us to waste computational resources.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26863
Summary:
According to the xdg-shell spec, configure events carry the maximum
window geometry size. If a client wants to enforce aspect ratio, it
may attach a buffer with smaller size. We need to account for that
when determining frame geometry in the commit handler.
I'm targeting 5.18 branch.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26886
Summary:
So far the window geometry from xdg-shell wasn't implemented as it should
be. A toplevel must have two geometries assigned to it - frame and buffer.
The frame geometry describes bounds of the client excluding server-side
and client-side drop-shadows. The buffer geometry specifies rectangle on
the screen occupied by the main surface.
State and geometry handling in XdgShellClient is still a bit broken. This
change doesn't intend to fix that, it must be done in another patch asap.
Test Plan: New tests pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24455
Summary:
on X11, setFullScreen is always called after Placement::place()
so they always have the correct geometry.
on wayland, the window if is shown directly as fullscren,
is set fullscreen in init() then place() is evecuted, potentially
moving it to a wrong position and potentially even size (which happens
with maximiziong placement strategy)
so instead of place() the client needs to be explicitly set at
fullscreen geometry
Test Plan:
fullscreen windows always appear with the proper geometry
autotests still pass
Reviewers: #kwin, #plasma, davidedmundson
Reviewed By: #kwin, #plasma, davidedmundson
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24542
Summary:
In order to properly implement xdg_surface.set_window_geometry we need
two kinds of geometry - frame and buffer. The frame geometry specifies
visible bounds of the client on the screen, excluding client-side drop
shadows. The buffer geometry specifies rectangle on the screen that the
attached buffer or x11 pixmap occupies on the screen.
This change renames the geometry property to frameGeometry in order to
reflect the new meaning assigned to it as well to make it easier to
differentiate between frame geometry and buffer geometry in the future.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24334
Summary:
Rename ShellClient to XdgShellClient in order to reflect that it
represents only xdg-shell clients.
Test Plan: Compiles, tests still pass.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23589
