There's some X11-reliance in Toplevel which is ideally split out but for now let's check for info being null.
For instance, accessing pid() on a deleted Wayland client can crash when it's no longer a XdgShellClient.
Differential Revision: https://phabricator.kde.org/D28101
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:
When a window is being interactively resized, its contents may jump. The
reason why that happens is because KWin renders partially resized client
window. Composite extension spec says that a window will get a new pixmap
each time it is resized or mapped. This applies to the frame window, but
not to the client window itself. If the client window is resized,
off-screen storage for the frame window won't be reallocated. Therefore,
KWin may render partially resized client window if the client doesn't
attempt to be in sync with our rendering loop. Currently, the only way
to do that is to use extended frame counters, which are not supported by
KWin.
So, in order to fix visual artifacts during interactive resize, we need
somehow forcefully re-allocate off-screen storage for the frame window.
Unfortunately, Composite extension doesn't provide any request to do
that, so the only option we have is to resize the frame window.
BUG: 415839
FIXED-IN: 5.18.0
Reviewers: #kwin
Subscribers: davidedmundson, ngraham, alexde, fredrik, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26914
Summary: The new name better reflects what Toplevel::geom is.
Test Plan: Compiles, tests still pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25738
This reverts commit 9151bb7b9e.
This reverts commit ac4dce1c20.
This reverts commit 754b72d155.
In order to make the fix work, we need to redirect the client window
instead of the frame window. However, we cannot to do that because
Xwayland expects the toplevel window(in our case, the frame window)
to be redirected.
Another solution to the texture bleeding issue must be found.
CCBUG: 257566
CCBUG: 360549
Summary:
Since KDE 4.2 - 4.3 times, KWin doesn't paint window decorations on real
X11 windows, except when compositing is turned off. This leaves us with
a problem. The actual client contents is inside a larger texture with no
useful pixel data around it. This and decoration texture bleeding are
the main factors that contribute to 1px gap between the server-side
decoration and client contents with effects such as wobbly windows, and
zoom.
Another problem with naming frame pixmap instead of client pixmap is
that it doesn't quite go along with wayland. It only makes more difficult
to abstract window quad generation in the scene.
Since we don't actually need the frame window when compositing is on,
there is nothing that holds us from redirecting client windows instead
of frame windows. This will help us to fix the texture bleeding issue
and also help us with the ongoing redesign of the scene.
Test Plan: X11 clients are still composited.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25610
Summary:
Qt has its own thing where a type might also have corresponding list
alias, e.g. QObject and QObjectList, QWidget and QWidgetList. I don't
know why Qt does that, maybe for some historical reasons, but what
matters is that we copy this pattern here in KWin. While this pattern
might be useful with some long list types, for example
QList<QWeakPointer<TabBoxClient>> TabBoxClientList
in general, it causes more harm than good. For example, we've got two
new client types, do we need corresponding list typedefs for them? If
no, why do we have ClientList and so on?
Another problem with these typedefs is that you need to include utils.h
header in order to use them. A better way to handle such things is to
just forward declare a client class (if that's possible) and use it
directly with QList or QVector. This way translation units don't get
"bloated" with utils.h stuff for no apparent reason.
So, in order to make code more consistent and easier to follow, this
change drops some of our custom typedefs. Namely ConstClientList,
ClientList, DeletedList, UnmanagedList, ToplevelList, and GroupList.
Test Plan: Compiles.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24950
Summary:
KDE is known for having a strong view on the client-side decorations vs
server-side decorations issue. The main argument raised against CSD is
that desktop will look less consistent when clients start drawing window
decorations by themselves, which is somewhat true. It all ties to how
well each toolkit is integrated with the desktop environment.
KDE doesn't control the desktop market on Linux. Another big "player"
is GNOME. Both KDE and GNOME have very polarized views on in which
direction desktop should move forward. The KDE community is pushing more
toward server-side decorations while the GNOME community is pushing
more toward client-side decorations. Both communities have developed
great applications and it's not rare to see a GNOME application being
used in KDE Plasma. The only problem is that these different views are
not left behind the curtain and our users pay the price. Resizing GTK
clients in Plasma became practically impossible due to resize borders
having small hit area.
When a client draws its window decoration, it's more likely that it also
draws the drop-shadow around the decoration. The compositor must know
the extents of the shadow so things like snapping and so on work as
expected. And here lies the problem... While the xdg-shell protocol has
a way to specify such things, the NetWM spec doesn't have anything like
that. There's _GTK_FRAME_EXTENTS in the wild, however the problem with
it is that it's a proprietary atom, which is specific only to GTK apps.
Due to that, _GTK_FRAME_EXTENTS wasn't implemented because implementing
anything like that would require major changes in how we think about
geometry.
Recent xdg-shell window geometry patches adjusted geometry abstractions
in kwin to such a degree that it's very easy to add support for client
side decorated clients on X11. We just have to make sure that the
X11Client class provides correct buffer geometry and frame geometry when
the gtk frame extents are set.
Even though the X11 code is feature frozen, I still think it's worth
to have _GTK_FRAME_EXTENTS support in kwin because it will fix the resize
issues. Also, because KWin/Wayland is unfortunately far from becoming
default, it will help us with testing some implementation bits of the
window geometry from xdg-shell.
BUG: 390550
FIXED-IN: 5.18.0
Test Plan:
Things like quick tiling, maximizing, tiling scripts and so on work as
expected with GTK clients.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: cblack, trmdi, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24660
Summary:
Currently our Scene is quite naive about geometry. It assumes that the
window frame wraps the attached buffer/client. While this is true for X11
clients, such geometry model is not suitable for client-side decorated
clients, in our case for xdg-shell clients that set window geometry
other than the bounding rectangle of the main surface.
In general, the proposed solution doesn't make any concrete assumptions
about the order between frame and buffer geometry, however we may still
need to reconsider the design of Scene once it starts to generate quads
for sub-surfaces.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24462
Summary:
The damage region is in surface-local coordinates, while the repaints
region is in frame-local coordinates, i.e. relative to the top-left
corner of the frame geometry.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24460
Summary:
Frame and buffer geometry don't have strict order. Either one of them can
be inside the other one, so we must take that into account when computing
visible bounds of the client including drop-shadows. We also have to take
sub-surfaces into account when determining the visible rect, however it's
out of scope for this patch.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Maniphest Tasks: T10867
Differential Revision: https://phabricator.kde.org/D24458
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: getShadow is not a getter method as it doesn't return a shadow.
Test Plan: Compiles.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24298
Summary:
Currently each managed X11 client is represented with an instance of
Client class, however the name of that class is very generic and the
only reason why it's called that way is because historically kwin
was created as an x11 window manager, so "Client" was a sensible choice.
With introduction of wayland support, things had changed and therefore
Client needs to be renamed to X11Client in order to better reflect what
that class stands for.
Renaming of Client to X11Client was agreed upon during the last KWin
sprint.
Test Plan: Compiles, the test suite is still green.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24184
Summary:
So far wayland was used by internal clients to submit raster buffers
and position themselves on the screen. While we didn't have issues with
submitting raster buffers, there were some problems with positioning
task switchers. Mostly, because we had effectively two paths that may
alter geometry.
A better approach to deal with internal clients is to let our QPA use
kwin core api directly. This way we can eliminate unnecessary roundtrips
as well make geometry handling much easier and comprehensible.
The last missing piece is shadows. Both Plasma::Dialog and Breeze widget
style use platform-specific APIs to set and unset shadows. We need to
add shadows API to KWindowSystem. Even though some internal clients lack
drop-shadows at the moment, I don't consider it to be a blocker. We can
add shadows back later on.
CCBUG: 386304
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, kwin
Tags: #kwin
Maniphest Tasks: T9600
Differential Revision: https://phabricator.kde.org/D22810
Summary:
Because KWin is a very old project, we use three kinds of null pointer
literals: 0, NULL, and nullptr. Since C++11, it's recommended to use
nullptr keyword.
This change converts all usages of 0 and NULL literal to nullptr. Even
though it breaks git history, we need to do it in order to have consistent
code as well to ease code reviews (it's very tempting for some people to
add unrelated changes to their patches, e.g. converting NULL to nullptr).
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson, romangg
Reviewed By: #kwin, davidedmundson, romangg
Subscribers: romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23618
Summary:
This has been commented out since 2014, I doubt it will come back.
This is a big amount of code, maintenance will be easier without it.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: romangg, graesslin, kwin
Tags: #kwin, #documentation
Differential Revision: https://phabricator.kde.org/D23069
Summary:
Switch to Q_ASSERT in order to make code a bit more consistent. We have
places where both assert and Q_ASSERT are used next to each other. Also,
distributions like Ubuntu don't strip away assert(), let's hope that
things are a bit different with Q_ASSERT.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23605
Summary:
So far we were following a bit unique and rare doxygen comment style:
/**
* Contents of the comment.
**/
Doxygen comments with this style look balanced and neat, but many people
that contribute to KWin don't follow this style. Instead, they prefer
more traditional doxygen comment style, i.e.
/**
* Contents of the comment.
*/
Reviewing such changes has been a bit frustrating for me (so selfish!)
and for other contributors.
This change switches doxygen comment style in KWin to a more traditional
style. The main reason for doing this is to make code review process easier
for new contributors as well us.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22812
Summary:
QRegion::rects was deprecated in Qt 5.11. It is advised to use begin()
and end() methods instead.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22353
Summary:
Compositing today is ubiquitous. There is no reason to keep compositing
specific functions of Toplevel, Client and Workspace classes in the
composite.cpp source file. Instead let these definitions be separated.
Test Plan: Compiles
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Maniphest Tasks: T11071
Differential Revision: https://phabricator.kde.org/D21654
Summary:
We have a mix of different doxygen comment styles, e.g.
/*!
Foo bar.
*/
/**
* Foo bar.
*/
/** Foo bar.
*/
/**
* Foo bar.
*/
/**
* Foo bar.
**/
To make the code more consistent, this change updates the style of all
doxygen comments to the last one.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18683
Summary:
If a Toplevel has scheduled layer repaints, then we have to copy them
to Deleted as well. This can happen, for example, when a client loses
shadow right before it gets closed or unmapped.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18786
Summary:
TabGroup is nowadays in AbstractClient so the cast to Client is
incorrect.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17898
Summary:
The dialog invoked through user actions menu takes the internal uuid as
command line argument which allows to query the required information
from KWin instead of using X11.
This allows to enable the system for Wayland windows.
In order to replace the usage of ClientMachine in the rules dialog the
dbus interface is extended by a value whether the window is on the
localhost. This is exposed through a virtual method on toplevel which is
overridden in ShellClient and there always returning true.
Test Plan: Run a nested Wayland and opened the dialog on a wayland window
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17750
Summary:
If updating a shadow means that there should be no shadow, shadow ends
up deleting itself midway through the method.
It's cleaner and safer to leave that to the caller.
This new change matches the existing documentation for
Shadow::updateShadow which states
> In case the Property has been withdrawn the method returns @c false.
> In that case the owner should delete the Shadow.
Test Plan:
Created an ASAN of kwin
Relevant testMaximised no longer fails
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D17380
Summary:
For supporting Wayland windows in the kwin_rules_dialog we need a way to
pass a window id for Wayland windows to the dialog. This id needs to be
sent to the dbus interface to query window information just like the
interactive query. For Wayland windows we don't really have a window id
and it would require to also pass the windowing system to
kwin_rules_dialog and back through the dbus interface.
To not complicate things this change introduces a windowing system
independent id based on UUID. This could in future also be used
internally for areas where it's window id based and used in both
windowing systems.
Test Plan: Adjusted test cases to verify the uuid is generated and passed to Deleted
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16986
Summary:
Under wayland we support high DPI putting by putting a separation
between the logical co-ordinate system and the resolution of rendered
assets.
When a window is on a high DPI screen, we should render at the higher
resolution.
Like the window scaling this handles any combination of a 2x scaled
decoration being rendered on a 1x screen or vice versa.
---
This patch is a bit different from the other scaling stuff. We have to
generate the quads *before* we have an updated texture with the new
scale. This means the scale isn't attached to the buffer like elsewhere.
That's why I added a property in TopLevel so there's still one canonical
source and things can't get out of sync.
BUG: 384765
Test Plan:
Crystal clear breeze and oxygen decos on my @2x display
Drag windows to attached @1x display, things still look OK when across 2
screens
Changing the scale of a screen updated the decos instantly
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8600
Summary:
This change adds support for resizing outside the window decoration
(e.g. setting borders to NoSide or None).
To support this a new Toplevel::inputGeometry() -> QRect method is
added which exposes the geometry adjusted by the margins provided by
the decoration. This is checked in InputRedirection when finding a
Toplevel at a given position. The logic for figuring out whether the
event should go to the decoration or the window already handled the
situation correctly, so no further changes are needed.
BUG: 364607
FIXED-IN: 5.8.1
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2787
Summary:
So far this connect was only in ShellClient, but it's needed for all
Toplevels. Also when a XWayland window has it's surface size changed,
the pixmap needs to be discarded. Otherwise KWin might hit an assert
in AbstractEGLTexture due to the buffer having a different size than
the texture had previously.
Test Plan:
Firefox, click download on bugreports.qt.io used to trigger
this for me. With this change no longer able to reproduce.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2583
Summary:
Rational: unredirect fullscreen windows is a weird beast. It's intended
to make fullscreen windows "faster" by not compositing that screen. But
that doesn't really work as KWin jumps out of that condition pretty
quickly. E.g. whenever a tooltip window is shown. KWin itself has a
better functionality by supporting to block compositing completely.
The complete code was full of hacks around it to try to ensure that
things don't break.
Overall unredirect fullscreen has always been the odd one. We had it
because a compositor needs to have it, but it never got truly integrated.
E.g. effects don't interact with it properly so that some things randomly
work, others don't. Will it trigger the screenedge, probably yes, but
will it show the highlight: properly no.
By removing the functionality we finally acknowledge that this mode is
not maintained and has not been maintained for years and that we do not
intend to support it better in future. Over the years we tried to make
it more and more hidden: it's disabled for Intel GPUs, because it used
to crash KWin. It's marked as an "expert" option, etc.
It's clearly something we tried to hide from the user that it exists.
For Wayland the whole unredirect infrastructure doesn't make sense
either. There is no such thing as "unredirecting". We might make use
of passing buffers directly to the underlying stack, but that will be
done automatically when we know it can be done, not by some magic is
this a window of specific size.
Test Plan:
Compiles, cannot really test as I am an Intel user who never
had that working.
Reviewers: #kwin, #plasma, #vdg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2180
Summary:
For XWayland windows the window might be activated before the Wayland
Surface is set for it. Thus the keyboard focus is not passed to the
window. Only on the next activate after the window got created the
window got keyboard focus.
This change addresses this problem by emitting a signal from Toplevel
when the surface changes. The KeyboardInput listens to this signal
for the active client and updates keyboard focus again if the surface
changes. Thus keyboard focus is properly passed to XWayland windows.
Test Plan:
Test case which creates an X11 window is adjusted to verify
the condition.
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2009
Summary:
Toplevel::window() is the actual X11 window. This makes it difficult
to use as the generic identifier for both X11 and Wayland. The Wayland
ShellClient already had a windowId() which is now added to Toplevel as
a virtual method. On X11 (Toplevel default) it returns the window().
The method window() now returns XCB_WINDOW_NONE for classes without
the Toplevel::m_client, such as ShellClient. Thus it allows to properly
check whether we are on Wayland or X11.
The code is adjusted to use windowId where a generic id is needed and
to properly check whether the window is valid before using it where
a window() is used.
This also fixes at least one additional unknown issue in
Workspace::setActiveClient
where the windowId of a Wayland client was passed to X11.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1527
The damage event of the Surface does not consider the offset through
the server side decoration. Due to that we need to have a different
repaint and damage area. As Toplevel::addDamage(QRegion) is only used
in the Wayland case the repaint adjustment is removed from the generic
implementation and moved into the specific implementations. While it
wouldn't hurt to have the repaint adjustment in Toplevel, it would
trigger a repaint of an unchanged area.
For Client I'm not sure whether it's correct without considering the
clientPos. My testing shows it's working, but that might also just be
do to Xwayland using OpenGL buffers. Needs further testing.
This legacy session management scheme using the WM_COMMAND property
seems to be called XSM. It is very, very legacy because it was
superseded by XSMP in 1993(!).
By inspecting ~/.config/session/kwin_[...] I could see that Firefox
still sets WM_COMMAND, but nothing else in a regular session with
some applications.
As one of the last applications to switch to XSMP session management,
I guess Firefox keeps doing that because it still needs to work on,
say, Solaris, anyway, so why not set WM_COMMAND on Linux as well.
The WM_COMMAND set by Firefox looks like "wmCommand8=firefox\s" in
the kwin session file. It doesn't actually contain a session
identifier. But then, Firefox only has one session per user anyway.
This goes together with commit 5f0ca1305db4a925 in plasma-workspace /
ksmserver to remove legacy session management support.
I've talked about my plan to do this on IRC with Martin so hopefully
it's okay to just do this now.
InputRedirection uses the inputTransformation() to pass to SeatInterface
for focused pointer surface. This prepares for proper input
transformation including scaling and rotation.
This change introduces a mechanism for internal windows to be rendered
to a QOpenGLFramebufferObject to be composited using the texture bound
to the FBO. This is useful for in-process rendering (e.g. QtQuick) and
at the same time bypassing the windowing system.
The OpenGL context of the QOpenGLFramebufferObject needs to be sharing
with the compositing OpenGL context.
For the appId we use:
* wl_shell windowClass for Wayland clients
* resourceName from window class for X11 clients
This is implemented by sharing the window class implementation in
Toplevel.
CCMAIL: hein@kde.org
