On X11 there is a really cool feature that allows users to make a window disappear and keep only its title bar visible. It is accomplished by hovering the title bar and scrolling up with the mouse (scroll down to make the window visible again). On Wayland, I can achieve it only with XWayland windows.
Created attachment 104346 [details] attachment-24320-0.html Window shading is currently only implemented for X11 windows.
Btw. even when implemented we will only be able to offer it for Qt applications as GTK uses client side decorations. Overall I want to implement shading just to reduce the differences, but it does not have a high priority as shading is nowadays a hardly used feature.
Still not working. Operating System: Arch Linux KDE Plasma Version: 5.17.90 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.1
Window shading now seems to be working for non-Qt apps. Doesn't work for kde /qt apps. Operating System: KDE neon 5.22 KDE Plasma Version: 5.22.3 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.3 Kernel Version: 5.8.0-59-generic (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: Radeon RX 580 Series
*** Bug 443481 has been marked as a duplicate of this bug. ***
(In reply to Zamundaaa from comment #5) > *** Bug 443481 has been marked as a duplicate of this bug. *** Thank you. This feature, historically unique to KDE since many years, really deserves to be known and thus implemented for Wayland ? And so much powerful when combined with always on top!.. Is it that hard to develop since 2017 ?
There's a WIP for it: https://invent.kde.org/plasma/kwin/-/merge_requests/1183
(In reply to Zamundaaa from comment #7) > There's a WIP for it: > https://invent.kde.org/plasma/kwin/-/merge_requests/1183 Thank you so much !
*** Bug 445640 has been marked as a duplicate of this bug. ***
Can confirm. Seems that the MR was closed. Any other progress related?
*** Bug 459034 has been marked as a duplicate of this bug. ***
Hi. I just read Nate's https://pointieststick.com/2022/12/31/highlights-from-2022/, in which he said "Our list of showstoppers continues to shrink, and new issues added to it are or notably less bad than the ones they replace. ... And if you’re tempted to grumble, “well, Wayland still doesn’t work for me for $REASON,” please do it in a bug report so developers can fix it!". So, i decided to make a bug report for W's lack of window shading, but found this [& other] existing BRs for it. Your Wayland progress has been collectively wonderful [thanks!], such that since 5.25.x i've been able to use it as my daily tool for large swathes of contiguous session-time. Every now & then, though, i retreat to X11 for two main reasons; 1. The ongoing misbehaviour in W of PiP, per https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/44; 2. the tragic ongoing lack of window shading in W, per this current bug report. In the next few hours when i've completed some current stuff, i intend to logout of W & back into X again, as i genuinely miss those very productive features. I'd like to record these: a. afaik this problem has never been included in the Showstoppers at https://community.kde.org/Plasma/Wayland_Showstoppers; certainly at least it's not there now nor for the past year. For MY use-case, it IS a showstopper, & i suspect i'm far from alone. b. Martin, above, said "it does not have a high priority as shading is nowadays a hardly used feature". That statement shocks me, so i wish to strenuously protest it as a counter-opinion. c. Yan, above, said "This feature, historically unique to KDE since many years". I don't think this is correct. Cinnamon & Xfce, at least, most definitely have shading [X11 only, ofc], so Plasma's absence of this in Wayland is a distinct functionality degradation IMO. Please, can we Shaders have any cause for hope in Plasma 5.27.x's or more likely 6.x's Wayland? *** Operating System: Arch Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 5.15.85-1-lts (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-4790 CPU @ 3.60GHz Memory: 30.8 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4600
Adding it to that page seems reasonable as there does seem to be quite a lot of demand for this feature.
Especially, if you really want to convert the long term power users! A not too small share of them make use of this feature. If you get used to it, you will not want to do without it.
The merge request (https://invent.kde.org/plasma/kwin/-/merge_requests/1183) has thankfully since been reopened but hasn't seen much more action in the last 5 months. Going to pop a ping to see if we can reinvigorate the activity.
Hi, if I wanted to take care of this MR - https://invent.kde.org/plasma/kwin/-/merge_requests/1183/diffs - and make sure it gets merged into master, what would I need to do? Communicate to the author if he's still up to resolve the comments? If not, could I do that instead of him? Not sure what the agreed policy on this is, sorry if it's something obvious or well known, I'm just getting into contributing :)
You could re-submit it yourself, addressing comments on the last one. You can always make your case. But there is no guarantee that it will be merged.
I've just read https://pointieststick.com/2023/05/11/plasma-6-better-defaults/. I'm most dismayed to see, afaik, that during this review, the team apparently removed the *only-relatively-recently-added* item for **window shading / rollup**, per https://bugs.kde.org/show_bug.cgi?id=377162#c13 above [which DID briefly then appear thereafter]. Ofc i can understand that some Devs might not have wanted it in the new priority category, but to also then omit it from the secondary category is very saddening. Is this really now the end of the road for it?
We might add it back to the "annoyances" section. Unfortunately the fact remains that it's quite a niche feature that's hard to support properly on Wayland. Nobody's vetoed it, so there's always a chance it will get implemented there, but it will most likely require a DIY effort by someone who really loves it.
*** Bug 473041 has been marked as a duplicate of this bug. ***
*** Bug 474553 has been marked as a duplicate of this bug. ***
Another response to indicate that lack of shading is an impediment to my fully moving to a Wayland based system. This is so ingrained in my daily operation that not having becomes a process stumbling block. Please consider implementing this as soon as possible in light of the future move of major OS's to Wayland.
*** Bug 479381 has been marked as a duplicate of this bug. ***
*** Bug 481279 has been marked as a duplicate of this bug. ***
*** Bug 482220 has been marked as a duplicate of this bug. ***
Following a fresh install of KDE Neon 6.0, I've set up a few panel widgets to run Chrome apps, using the "--app=" argument. These seem to shade correctly. I thought perhaps these were ignoring the Window Behaviour system settings altogether, but if I set the Titlebar Action to "Minimse", rather than "Shade", then they correctly minimise, as do other windows. Very odd.
This is an annoying bug in Wayland - I've just gotten so used to setting mouse wheel to shade/unshade and the upgrade to Plasma6 & Wayland without this means I've lost a major plus feature. Operating System: openSUSE Tumbleweed 20240319 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.1-1-default (64-bit) Graphics Platform: Wayland
(In reply to Alan Prescott from comment #27) > This is an annoying bug in Wayland - I've just gotten so used to setting > mouse wheel to shade/unshade and the upgrade to Plasma6 & Wayland without > this means I've lost a major plus feature. > > Operating System: openSUSE Tumbleweed 20240319 > KDE Plasma Version: 6.0.2 > KDE Frameworks Version: 6.0.0 > Qt Version: 6.6.2 > Kernel Version: 6.8.1-1-default (64-bit) > Graphics Platform: Wayland Aha. I used Mouse Gestures heavily in the past - to manage my windows mostly - as well as occasionally shading a window here and there... Now that we're moving to Wayland, and leaving (at least for now...) the likes of 'Easystroke' and hoping for development on the likes of 'Mouse Actions' then this redundant (visible, but not working) feature is rather a nasty tease.