foreign-toplevel-management: Allow to emit toplevels responsiveness state

AFAIK we currently don't have a way for the compositor to inform interested clients about toplevels not answering to ping events. Adding that functionality would allow desktop shells to inform the user about the state of the app (and e.g. allow to force quit it).

I'm not 100% happy about the responsiveness terminology but pingable seemed to restrictive as compositors might use different methods to determine that a toplevel is still usable by the user.

added time estimate of

added 1 commit

• 263e9af5 - foreign-toplevel-management: Allow to emit toplevels responsiveness state

Compare with previous version

What would be the use case for a toplevel not answering a ping event beside being stalled?

The client can provide feedback to the user and (depending on the amount of knowledge about the application) offer to e.g. force kill it.

added 1 commit

• 59494eac - foreign-toplevel-management: Allow to emit toplevels responsiveness state

Compare with previous version

v1.1

• drop unknown state
• Specify state when compositor didn't send an event

I wonder, would it make sense to add in the existing state enum?

mentioned in merge request wlr-clients!5

mentioned in merge request wlroots!4924

added 1 commit

• f6d899a5 - foreign-toplevel-management: Allow to emit toplevels responsiveness state

Compare with previous version

added 1 commit

• 4ea687f0 - foreign-toplevel-management: Allow to emit toplevels responsiveness state

Compare with previous version

v1.2

• Drop responsive state. When unresponsive is not part of the state we assume responsive.

mentioned in merge request wayland/wayland-protocols!196