RFC: color scheme protocol
Goal: provides global color scheming across clients per seats.
Compared to #100 and #57, this implements both by providing preferred color schemes. Each color scheme has a set name and brightness (light/dark). This protocol would also provide the ability for clients to create new color schemes.
Interfaces
zwp_color_scheme_manager_v1
Will provide access to managing the color schemes and notifying when a color scheme is removed or added.
Event: changed
This will notify the clients when the preferred color scheme has changed.
Event: scheme_added
This will notify the clients when a new color scheme has been added.
Event: scheme_removed
This will notify the clients when a color scheme has been removed.
Method: create
Creates a new color scheme for a specific brightness target and with a specific name. The created color scheme will then be owned by the client and attached to the provided seat.
Method: get_preferred
Retrieves the color scheme the compositor wants the client on a seat to use.
Method: set_preferred
Sets the active color scheme to use on the seat, if the compositor doesn't want the client to use it then ignore.
zwp_color_scheme_v1
An interface which represents a whole color scheme.
Event: begin
This will tell the client that the descriptive event sequence has begun by providing the name and brightness target.
Event: done
This will tell the client the descriptive event sequence has completed.
Method: get_color
Retrieves a color by using a value of the color enum and an index. The purpose of making colors indexable allows for creating a large range of colors which could be mixed.
Method: create_color
Allows for the color scheme's owner client to add a new color to the colorscheme. If the current client is not an owner then returns an already defined color.
NOTE: I wanted this to return NULL but didn't see any sort of way to use allow-null with a return argument. If there is another way to error out and prevent weird behavior then we should definitely change this.
Method: (destructor) release
Releases the reference of the interface.
Method: (destructor) destroy
If the client owns the interface then destroy it completely, this will cause the scheme_removed event in the manager. If the client doesn't own the color scheme then just release it.
zwp_color_v1
An interface which defines a single RGBA color. The full size of a single color can be represented as UINT32_MAX * 4.
Event: channel
An event which notifies the value for a specific RGBA color channel.
Method: set_channel
If the client owns the interface then sets the specified RGBA color channel with the given value.
Method: (destructor) release
Releases the reference of the interface.
Method: (destructor) destroy
If the client owns the interface then destroy it completely. If the client doesn't own the color then just release it.
Enums
Brightness
Describes a brightness target. This can be used to differentiate the general contrast of a theme.
- light
- dark
Color
Describes a color entry in the pallet for a color scheme.
- primary
- secondary
- tertiary
- Background
- Foreground
- Surface
- Accent
- Warning
- Error
- Info
- Shadow
Indexable colors
These colors are still a part of the color enum but are ones which have indexes. This allows for having a range of colors to utilize for basic colors.
- Blue
- Green
- Red
- Black
- White
Channel
An RGBA (Red, Green, Blue, Alpha) color channel.
- Red
- Green
- Blue
- Alpha
Problems
1. What do we do when a client is destroyed but wants to keep the color scheme?
To ensure security, the color scheme protocol only allows control of color schemes which are owned by a client it is created by. The problem we can run into is "What should we do when the color scheme should exist but isn't released".
Solution 1
Destroy the color scheme, because the client was destroyed this must mean the color scheme should exist. This causes some issues where a color scheme could be wanted but not the client.
Solution 2
Keep it until compositor is destroyed, this may be the best solution but we run into a problem where it cannot be changed. Does this mean we should require the compositor to be restarted in order to release all "limbo" color-schemes.
2. Colors other than RGBA
Should we only be using RBGA or should we return a single pixel color buffer? Should we make the client responsible for transforming colors or should be support giving a color format in the zwp_color_scheme_v1::get_color() request?
3. Should the color names be strings or just stick with an enum?
I chose an enum to limit the amount of possible choices to prevent others from setting nonsensical color names. However, there's a case to be made about compatibility and specially unsupported color names.
4. Handling errors when an object is not owned by the current client
What should we do in this case? Should every interface have an error event which the client listens on?
5. Should terminal emulators use the already existing colors in this protocol or get their own separate set of colors?
There is a case for whether or not terminal emulators should get their own set of colors in the color scheme, could be prefixed with terminal_.
Support with other protocols
Server Side Decorations
This protocol could be utilized with server side decorations to allow matching server side decorations.
Author's use
I've drafted a first iteration of it as described by this issue for use in my own Linux based operating system. I would like to see upstream support for a protocol like the one I have outlined.