From 16e85c6b444ce57a26fbd63121fe874b6d732591 Mon Sep 17 00:00:00 2001 From: Arun Mani J Date: Thu, 3 Oct 2024 17:33:37 +0530 Subject: [PATCH] foreign-toplevel-management: Add responsiveness event This event can be used to inform compositors if a toplevel is responsive or not. --- ...oreign-toplevel-management-unstable-v1.xml | 26 +++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/protocol/wlr-foreign-toplevel-management-unstable-v1.xml b/protocol/wlr-foreign-toplevel-management-unstable-v1.xml index 108133715..d344c7f17 100644 --- a/protocol/wlr-foreign-toplevel-management-unstable-v1.xml +++ b/protocol/wlr-foreign-toplevel-management-unstable-v1.xml @@ -25,7 +25,7 @@ THIS SOFTWARE. - + The purpose of this protocol is to enable the creation of taskbars and docks by providing them with a list of opened applications and @@ -68,7 +68,7 @@ - + A zwlr_foreign_toplevel_handle_v1 object represents an opened toplevel window. Each app may have multiple opened toplevels. @@ -266,5 +266,27 @@ + + + + + + The different responsiveness states that a toplevel can have. If the client didn't receive + any event from the compositor it should assume the client is responsive. + + + + + + + + + This event is emitted when the compositor detects a change in the toplevels responsiveness. + An unresponsive toplevel usually doesn't respond to ping requests send by the compositor + while a responsive one does but a compositor might use more elaborate means to detect if a + toplevel is still usable by the user. + + +