Conclusion: Client-side decorations absolutely suck and any proponent is a retard!
As I mentioned in the last posts, the video is from late 2010. There was no minimize support because back then, (there wasn't even a SHELL yet in 2010, which there IS now, so there was no place for minimized apps to go)
Right now, the minimize protocol patches are currently not yet merged. (Yes there has to be a protocol for minimize so that applications can tell which of it's windows should get a task entry, (and which ones should not, such as menus and tooltips)). I have tested them, and although I can't minimize from the window right now, I can minimize a hung surface by clicking on its entry on the panel. This proves that the Wayland protocol does not hinder Weston from being flexible with hung windows.
Perhaps in the future a helper tooltip could be attached to windows that are hung to provide a minimize button.
As far as moving with having to move hung surfaces with the super key, there was no ping protocol, which was added sometime last year (which means that feature did not exist when that video was filmed). Now Weston detects hung windows, and currently makes the entire window dragable without having to use the super key command.
Point is, Wayland is not going to introduce MS Windows type usability problems that you see with hung Windows applications, just because Wayland currently relies on using client side decorations. The Wayland protocol is stable in the sense that there is going to be no more API breakerage, but desktop features are still under development, and still need work in some areas.
(in fact what I think is with the issue with Windows is that the windows are somehow managed by the client as well as the decorations, I think I read that somewhere. With Wayland there IS a window manager.)
There's even some talk on the IRC of introducing a protocol that tells applications to not draw a decoration, and determine which applications should be decorated for optional server side decorations.
Wayland doesn't provide ANY ability to minimize apps yet. It's still being added.
The point is nothing will stop it from being able to allow frozen apps from being minimized. Once the functionality to do that for running apps is present, adding it for hung apps is TRIVIAL.
Learn to use basic problem solving skills.
While it will be supported, it will decidedly be a usability regression because of the need to poll the client, which is because Wayland's architecture.
Consider: I expect to be able to minimize* any window, any time, within 10ms**. No matter if the app is busy.
Under X, it works in all cases.
Under wayland, this would happen***: You click on minimize. Nothing happens. You wait 15 seconds. The app fades as unresponsive, and server controls are drawn. You have to re-click the new button.
This does three cardinal sins of user interface: it ignores your command, it makes you wait, and it makes you repeat your command. All usability regressions compared to the current state.
This is not possible to be worked around in the current design. Polling at 100Hz would waste your cpu unnecessarily, and even if it detected a hung app within 10ms, it would have to wait at least a second to avoid false positives. Kind of like Android touch screens have to wait after a tap to make sure it's not going to be a double tap (btw, I hate that wait as well. Terrible user design.).
* Optionally replace minimize here with mazimize, move, shade, and so on.
** The generally agreed usability limit is 100ms. My demands are stricter, but they are not unrealistic - X with a suitable WM has been able to meet that for years.
*** Based on reading the ping protocol patches.
If the compositor knows where and what size the window controls are (which it could know, if that information is provided within the theme), it could do the following:
1.) Detect a click in the area of the controls
2.) Passively wait for the client to notify it that an action was performed (minimize, close, etc.)
3.) If nothing is received within 100ms:
3.1) By default, force the action and tell the client that the action was forced.
3.2) If the client overrides the default, pop-up a window asking the user if he would like to close the unresponsive program.
Here, there is no polling. Only a few extra communications (only occurring when a click is performed within the bounds of the window controls), and a maximum wait time of 100ms (only if the program is unresponsive).
The compositor can simply make sure it gets a response within the prescribed amount of time whenever the user attempts some action on the window, and if no response is gotten it knows the app is hung. If the user isn't trying to interact with the window, then there is no reason to do anything to it, whether it's hung or not.
At 60Hz, that's six frames; at 70, 7 frames. (unless I calculated that wrong...)
.1s = 100ms, 60Hz = .016_frames/s, .1s/.016_frames/s = 6 frames
That's 1/10th of the monitor's refresh rate. Detectable, I guess, if you're paying attention. I guess the delay could reasonably be reduced to 50ms, or three frames, but I don't see that making a huge difference. I can see jitter and ghosting in some 60Hz displays in the store (which are probably configured improperly...meh), but I can't see much of a delay when tapping on my Android phone.
Previously it was only mentioned the compositor would know the location of the close button - if it has to know everything, that of course changes things.
The current code would do as I described, no?. The better solution only matters once it is implemented.
Also, if the mentioned solution was obvious, why was it not the first to be implemented, instead of the 15sec wait and friends?
Note that it's not just click events that it can watch - it can also ping the app whenever the mouse button enters the application window, so that if you are moving the mouse to click on the minimize/close buttons that 100ms timeout will likely hit before the mouse even reaches the buttons. Then it can draw the new UI on top of the window before you click at all.