color: define global_remove behavior

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_2756612
https://gitlab.freedesktop.org/wayland/wayland/-/issues/484

Toolkit authors are reluctant to handle the global removal, because on
most compositors the removal will never happen. OTOH, there is a
compositor author who wants to be able to change color-management
capabilities at runtime due to dynamically switching renderers.

This new wording strongly suggests the global is never removed to let
toolkits avoid all the code that removal tracking would need. Removal is
still technically allowed, but it is not generally expected that clients
would handle it.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This commit is contained in:
Pekka Paalanen 2025-02-06 15:41:00 +02:00
parent b2d34dd61d
commit f284a0cb85

View file

@ -73,11 +73,13 @@
<interface name="wp_color_manager_v1" version="1"> <interface name="wp_color_manager_v1" version="1">
<description summary="color manager singleton"> <description summary="color manager singleton">
A global interface used for getting color management extensions for A singleton global interface used for getting color management extensions
wl_surface and wl_output objects, and for creating client defined image for wl_surface and wl_output objects, and for creating client defined
description objects. The extension interfaces allow image description objects. The extension interfaces allow
getting the image description of outputs and setting the image getting the image description of outputs and setting the image
description of surfaces. description of surfaces.
Compositors should never remove this global.
</description> </description>
<request name="destroy" type="destructor"> <request name="destroy" type="destructor">