When an application is not responding, its window is desaturated to communicate this. Also "(Not Responding)" is added to the title bar.
Details
Details
- Reviewers
graesslin - Group Reviewers
VDG Plasma KWin - Commits
- R108:1eb950a98514: Desaturate non-responsive windows
(Originally created as https://git.reviewboard.kde.org/r/127162/ - in contrast to the older review, this here only changes the looks of the window, it leaves the kill prompt alone)
I'm absolutely certain there is a bug/wish on bko about this. X only right now, I don't think we have ping/kill infrastructure on Wayland yet?
VDG: When an application freezes and I click the close button, after 2.5s it will desaturate the window, after another 2.5s it will show the "do you want to kill $app" prompt. If I then choose "Wait longer", the prompt closes and the window remains desaturated until the app responds again. I can click the close button again, and get the "do you want to kill $app" prompt again (after 2.5s, for subsequent calls, though). It doesn't happen if you interact with the window in any other way, only the close button "pings" the client.
- Running the timer twice is probably more of a hack, when the client is already marked unresponsive, which halves the timeout when the kill dialog is triggered on subsequent invocations
Screenshots of a less colorful app (always 10% Saturation), proposals:
125% Brightness (original attempt)
80% Brightness (I don't really like this, looks mostly like the "dialog parent" effect; while this somewhat teaches people "dark window cannot be interacted with", I don't like it :p)
150% Brightness (my favorite, implemented in this updated patch, causes separator lines to fully wash out)
Diff Detail
Diff Detail
- Repository
- R108 KWin
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Comment Actions
Please adjust the autotests/test_*_effectloader.cpp - they would fail as you added an effect. Also please try running all autotests, we have some tests for the kill timeout, so your change might affect those.
| decorations/decoratedclient.cpp | ||
|---|---|---|
| 138–146 ↗ | (On Diff #12981) | instead of moving this into the decoration plugin, you could just adjust the caption directly. We already manipulate it anyway for adding things like (2). The advantage is that it would be available everywhere where we use the caption. E.g. Alt+Tab, PresentWindows... |
| effects.cpp | ||
| 540 | no cast on sender in new code please. We don't need this with lambda captures. | |
Comment Actions
My only concern is that many windows with the Breeze style have very little colour, some (like Kate) might not see the effect be distinguishable at all. Should we perhaps consider using an overlay colour selected from the colour scheme which we know will stand out? E.g. Tint the window contents the "Negative" (usually red) colour?
Comment Actions
This is something we do not know. We do not know what color scheme the window uses. Given that a desaturation is probably the best we can do.
Comment Actions
Lower brightness?
I actually increase the brightness to produce this washed-out effect but admittedly it doesn't look as good in less graphically intensive apps (I used Gwenview in the screenshot where you can tell easily but in Kwrite you probably can't). I'll try lowering the brightness instead.
Comment Actions
- Base frozenapp effect on dialogparent code, this fixes minimizing of frozen windows and also switching desktop (properly cancels and reapplies animation)
- Use lambda instead of sender() cast
- Adjust effectloader unittest
- Add "unresponsive" property to effect window (accessible from effect script)
- Manipulate caption() directly instead of doing that in deco (shows up in Alt+Tab now also)