Tag:
Branch:
Tree:
ef5406990e
Plasma/5.17
Plasma/5.20
Plasma/5.21
Plasma/5.22
Plasma/5.23
Plasma/5.24
master
upstream
wilder-Plasma/5.16
wilder-Plasma/5.17
wilder-Plasma/5.18
wilder-Plasma/5.19
wilder-Plasma/5.20
wilder-Plasma/5.23
wilder-Plasma/5.24
wilder-Plasma/5.25
wilder-Plasma/5.25-rebase
wilder-Plasma/5.26
wilder-Plasma/5.26-bottom-rebase-terse
wilder-Plasma/5.26-rebase
wilder-Plasma/5.26-rebase-terse
wilder-Plasma/5.26-tip-rebase
wilder-Plasma/5.26-works
wilder-Plasma/5.27
wilder-Plasma/5.27-bottom-rebase
wilder-last-point
wilder-master
wilder-master-debugging-multiscreen
wilder-master-rebase
wilder-master-rebase-stable
wilder/Plasma/6.2
wilder/Plasma/6.3
wilder/rebase-5.27
wilder/rebase-5.27-current
windowview-enhance
windowview-enhance-+debug
v4.96.0
v4.97.0
v4.98.0
v5.0.0
v5.0.1
v5.0.2
v5.0.95
v5.1.0
v5.1.1
v5.1.2
v5.1.95
v5.10.0
v5.10.1
v5.10.2
v5.10.3
v5.10.3.1
v5.10.4
v5.10.5
v5.10.95
v5.11.0
v5.11.1
v5.11.2
v5.11.3
v5.11.4
v5.11.5
v5.11.95
v5.12.0
v5.12.1
v5.12.2
v5.12.3
v5.12.4
v5.12.5
v5.12.6
v5.12.7
v5.12.8
v5.12.9
v5.12.90
v5.13.0
v5.13.1
v5.13.2
v5.13.3
v5.13.4
v5.13.5
v5.13.90
v5.14.0
v5.14.1
v5.14.2
v5.14.3
v5.14.4
v5.14.5
v5.14.90
v5.15.0
v5.15.1
v5.15.2
v5.15.3
v5.15.3.1
v5.15.3.2
v5.15.4
v5.15.5
v5.15.90
v5.16.0
v5.16.1
v5.16.2
v5.16.3
v5.16.4
v5.16.5
v5.16.90
v5.17.0
v5.17.1
v5.17.2
v5.17.3
v5.17.4
v5.17.5
v5.17.90
v5.18.0
v5.18.1
v5.18.2
v5.18.3
v5.18.4
v5.18.4.1
v5.18.5
v5.18.6
v5.18.7
v5.18.8
v5.18.90
v5.19.0
v5.19.1
v5.19.2
v5.19.3
v5.19.4
v5.19.5
v5.19.90
v5.2.0
v5.2.0.1
v5.2.1
v5.2.2
v5.2.95
v5.20.0
v5.20.1
v5.20.2
v5.20.3
v5.20.4
v5.20.5
v5.20.90
v5.21.0
v5.21.1
v5.21.2
v5.21.3
v5.21.4
v5.21.5
v5.21.90
v5.22.0
v5.22.1
v5.22.2
v5.22.3
v5.22.4
v5.22.5
v5.22.90
v5.23.0
v5.23.1
v5.23.2
v5.23.3
v5.23.4
v5.23.5
v5.23.90
v5.24.0
v5.24.1
v5.24.2
v5.24.3
v5.24.4
v5.24.5
v5.24.6
v5.24.7
v5.24.90
v5.25.0
v5.25.1
v5.25.2
v5.25.3
v5.25.4
v5.25.5
v5.25.90
v5.26.0
v5.26.1
v5.26.2
v5.26.3
v5.26.4
v5.26.5
v5.26.90
v5.27.0
v5.27.1
v5.27.2
v5.27.3
v5.27.4
v5.27.4.1
v5.27.5
v5.27.6
v5.3.0
v5.3.1
v5.3.2
v5.3.95
v5.4.0
v5.4.1
v5.4.2
v5.4.3
v5.4.95
v5.5.0
${ noResults }
7 Commits (ef5406990eb5a893e2f651cc3cdb7dd193f9bb0f)
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
64feafc10f |
Mark Toplevel as not ready for painting by default
Summary: Get rid of some duplication as InternalClient, XdgShellClient, Unmanaged, and Client initialize ready_for_painting to false. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D24189 |
7 years ago |
|
|
bebe81209c |
Port QPA away from Wayland
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 |
7 years ago |
|
|
18844f5925 |
[wayland] Apply window rules only to xdg-shell clients
Summary: There are rules that have to be applied only once, e.g. every Remember and Apply Initially rule, as well rules that need to configure the client, e.g. size, etc. In the best scenario the compositor would evaluate such rules when the client is about to be mapped. This change limits window rules only to xdg-shell clients because right now only this protocol lets compositors to intervene in the client initialization process. Also, it makes things a bit easier for us on the compositor side. xdg-shell protocol satisfies most of ours requirements to implement window rules, but not all of them. If the client is about to be mapped for the second time and its size is forced by a rule, then compositor may need to configure it. Currently, xdg-shell protocol doesn't have any mechanism that a client could use to notify the compositor about its intent to map. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: fmonteiro, davidedmundson, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19411 |
7 years ago |
|
|
baabd20ef6 |
Drop QOffscreenSurface guard
Summary:
Given that our QPA now creates native offscreen surfaces, we no longer
need the QOffscreenSurface guard introduced by
|
7 years ago |
|
|
61956025f0 |
Decorate only toplevel internal clients
Summary: Unfortunately Aurorae decoration engine creates several internal clients per each decoration. One of those clients represents QOffscreenSurface, which is not a toplevel. Given that no QWindow object will be found for such clients, m_internalWindowFlags contains undefined value. Luckily, QOffscreenSurface sets FramelessWindowHint flag, but because InternalClient is not able to find matching QWindow object, cached QWindow flags won't have that hint set. Thus InternalClient will attempt to decorate QOffscreenSurface. A new Aurorae decoration will be created, which means a new QOffscreenSurface will be created, which means a new Aurorae decoration will be created, and so on. This change restricts subset of internal clients that can be decorated. Only clients with valid m_internalWindow can be decorated. If m_internalWindow isn't null, then m_internalWindowFlags is guaranteed to be valid as well. BUG: 407612 FIXED-IN: 5.16.3 Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D22136 |
7 years ago |
|
|
3d46801e5f |
[wayland] Make sure that only the fading popups effect animates outline
Summary: Window open/close animation effects should not animate the outline because the end result is a bit awkward. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19886 |
7 years ago |
|
|
9b922f8833 |
Split out a dedicated InternalClient class
Summary: Most of the functionality which is special to internal clients is moved from ShellClient to InternalClient. As KWin's qpa is still bound to the Wayland protocol InternalClient inherits from ShellClient. Due to that some aspects in ShellClient are "weird". ShellClient still detects whether it's an internal client and uses the variable m_internal to capture the state. This is required as we cannot use the isInternal method. Most of m_internal usage is in init which is called from constructor of ShellClient. Thus it's not possible to call into virtual methods of InternalClient. Also some of the code is duplicated and some methods are temporarily marked as virtual. The next step will be to remove ShmBuffer for internal windows which should decouple the two implementations further with the long term goal of having InternalClient inherit AbstractClient directly. Test Plan: Run nested KWin, triggered outline (OpenGL case) and debug console (shm case). InternalWindow unit test still passes. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18569 |
7 years ago |