Add ext-foreign-toplevel-list protocol
- Apr 25, 2023
-
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
The new_id argument prevents this. Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
This makes the protocol more minimal and omits information that some usecases for a toplevel handle will not need. Information removed in this commit will be added in an extension protocol in the future. Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Alongside these clarifications, this makes the finished event get sent always when a stopped event is sent. Signed-off-by:
i509VCB <git@i509.me>
-
Open in the context of this protocol means a window visible to the user. Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Since multiple instances of ext_foreign_toplevel_info_v1 may exist per client, the compositor is required to create new ext_foreign_toplevel_handle_v1 objects for each global instantiation. This is key to allowing the globals to be used properly in a library, as the client itself and the library may wish to store different user data with the protocol object. Signed-off-by:
i509VCB <git@i509.me>
-
Libraries may instantiate the global, meaning a client could bind the global multiple times. Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
This commit applies some review comments I made on !155 In particular: - Destructor was added to ext_foreign_toplevel_info_v1 - Add error values to ext_foreign_toplevel_info_v1 - Add error for creating a second ext_foreign_toplevel_info_v1 - Add error when destroying ext_foreign_toplevel_info_v1 with existing child handles The rationale for the defunct_toplevels error is that it makes little sense to have the toplevel handles stay valid past the manager. Also the compositor can send the "finished" event to stop the global. - RFC 2119ify the protocol documentation - Describe how extension protocols should interact with the protocol. e.g. foreign-toplevel-management - Describe how to interpret the array payload in the ext_foreign_toplevel_handle_v1.state event Signed-off-by:
i509VCB <git@i509.me>
-
Signed-off-by:
i509VCB <git@i509.me>
-
This protocol provides the same information on toplevels as wlr-foreign-toplevel-management but does not allow the client to modify the state of said toplevels. This makes the protocol more suitable for use as a general way to address toplevels by protocol object, for example to integrate with the proposed ext-workspace protocol. Signed-off-by:
i509VCB <git@i509.me>
-