wilderjds/kwin - kwin - gitea-jacopods

Author	SHA1	Message	Date
Nicolas Fella	7159684ced	Revert "[kcm/effects] Clip ListView" Bad merge This reverts commit `b713044216`.	6 years ago
Nicolas Fella	b713044216	[kcm/effects] Clip ListView Summary: Otherwise the content overflows the frame when scrolling. QQC2 scrollview docs say "ScrollView does not automatically clip its contents. If it is not used as a full-screen item, you should consider setting the clip property to true" Test Plan: Before: {F8121150} After: {F8121152} Reviewers: #kwin, #plasma, ngraham Reviewed By: ngraham Subscribers: ngraham, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D27558	6 years ago
Nicolas Fella	cdc5ea19ab	Revert "[kcm/effects] Clip ListView" Bad merge This reverts commit `5babf52df4`.	6 years ago
Nicolas Fella	5babf52df4	[kcm/effects] Clip ListView Summary: Otherwise the content overflows the frame when scrolling. QQC2 scrollview docs say "ScrollView does not automatically clip its contents. If it is not used as a full-screen item, you should consider setting the clip property to true" Test Plan: Before: {F8121150} After: {F8121152} Reviewers: #kwin, #plasma, ngraham Reviewed By: ngraham Subscribers: ngraham, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D27558	6 years ago
Vlad Zahorodnii	fb598c65b8	Provide a KWindowShadow implementation for internal clients Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: davidedmundson, kwin Tags: #kwin Maniphest Tasks: T12496 Differential Revision: https://phabricator.kde.org/D26459	6 years ago
Martin Flöser	02a0561016	Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228	7 years ago
Martin Gräßlin	8dd0a8163f	[kcmkwin/kwindecoration] Import a new decoration configuration module Following features are supported: * finds all plugins ** finds all themes for a theme-engine plugin * renders previews for the plugin/themes * loads currently used plugin/theme * saves selected plugin/theme * triggers config reload in KWin Following features are currently not supported: * Search * Plugin configuration * GHNS * Button configuration	12 years ago
Martin Gräßlin	f0e1e3187e	Add a script to enforce window decorations for GTK windows This is going to be a controversal change. It enforces KWin decorations on all client side decorated windows from GTK+. Unfortunately we are caught between a rock and a hard place. Keeping the status quo means having broken windows and a more or less broken window manager due to GTK+ including the shadow in the windows. This is no solution. Enforcing server side decorations visually breaks the windows. This is also no solution. So why do it? It's our task to provide the best possible user experience and KWin is a window manager which has always done great efforts to fix misbehaving windows. One can think of the focus stealing prevention, the window rules and lately the scripts. The best possible window management experience is our aim. This means we cannot leave the users with the broken windows from GTK. The issues we noticed were reported to GTK+ about 2 months ago and we are working on improving the situation. Unfortunately several issues are not yet addressed and others will only be addressed in the next GTK+ release. We are working on improving the NETWM spec (see [1]) to ensure that the client side decorated windows are not in a broken state. This means the enforcment is a temporary solution and will be re-evaluated with the next GTK release. I would prefer to not have to do such a change, if some of the bugs were fixed or GTK+ would not use client-side-decos on wms not yet supporting those all of this would be a no issue. For a complete list of the problems caused by GTK's decos see bug [2] and the linked bug reports from there. The change is done in a least inversive way in KWin. We just check for the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it. If we add support for the frame extents in future we would also need this. So it's not a change just for enforcing the decoration. The actual enforcing is done through a KWin script so users can still disable it. REVIEW: 119062 [1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=729721	12 years ago