https://bugs.kde.org/show_bug.cgi?id=450582
--- Comment #34 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Hans-Peter Jansen from comment #33) > As a reminder: as far as I know, the Wayland protocol has no such concept of > shaded/shuttered windows. Therefore, preserving this feature in the longer > term would, in my humble view, require that such an option be considered in > the Wayland protocol itself. If anyone has more information on this topic, > please let me know. Thank you! Just thinking... What would it take? AFAIK/IMO, wayland protocol shading support would be nice, but isn't absolutely required, certainly for apps that are prepared to deal with kwin's compositor-side-decorations, as most modern wayland apps can, nowdays. Basically, it would require "lying" a bit to the app, telling it it's either mimimized/offscreen or a normal window, because telling it the real state, that it's shaded, isn't supported. In the former case, kwin would have to keep track of the previous window size and position, and continue drawing the (compositor-side for kwin) titlebar, but ONLY the titlebar. In the latter case, the app would think it was shown so would behave normally, but the kwin-compositor, always in charge of where and how the window is drawn in any case, would simply only draw the titlebar part of the (compositor-side) decoration, not the client/application window. The latter case, telling the app its window is normalized, which in some ways it effectively would be but with the app-window portion effectively 100% transparent or covered with 100% opacity (something a wayland app doesn't normally know in any case), would probably avoid some problems, but would use more power for apps that basically suspend themselves when they're not doing any output drawing anyway, as is the case when they're offscreen/minimized, because they wouldn't know that and would continue drawing their window as if it was visible. The former case, telling the app its window is minimized/offscreen, would likely be more complicated, as kwin would have to keep track of more state about the actual window that the app might not track when its minimized. Apps that update their titlebar frequently (think a resource monitor updating information in the titlebar every second, for instance) but suspend that updating when they're minimized/offscreen would be particularly troublesome, as the titlebar would still be displayed when shaded, but the title would simply stop updating. Either way it should be possible, even without direct protocol support. Someone, presumably someone with the necessary skills (which I don't claim to have) suitably motivated to scratch their own itch, just has to code it up and get it accepted. It /might/ even be doable as a kwin window management script, allowing it to be uploaded to the kde store, thus avoiding the "get it accepted" part it'd have to go through to become part of kwin proper. -- You are receiving this mail because: You are watching all bug changes.
