Mutter's clipboard manager doesn't take ownership of the CLIPBOARD_MANAGER selection
Mutter now has/is a clipboard manager but doesn't declare itself as such per the clipboard manager specification. This is not necessarily a bug, but it raises questions about what applications might want and expect when testing for clipboard persistence and using that functionality.
This follows on from a discussion here. A brief summary:
... the clipboard manager spec doesn't specifically mandate managers to implement SAVE_TARGETS conversion ... I'm thinking perhaps Mutter's clipboard manager should take ownership of
CLIPBOARD_MANAGER
If the client thinks we implement SAVE_TARGETS but we actually don't, that might lead to other issues.
So, IMHO the options are:
- Faking the 100% of a x11 clipboard manager
- Actually honoring it for X11 clients, and deal internally with the inconsistencies wrt Wayland.
- Not doing anything
It seems like it would be consistent with both the spec(s) and GTK's implementation if Mutter took ownership of
CLIPBOARD_MANAGER
and rejectedSAVE_TARGETS
conversion requests
There's at least the "what to do with 3rd party clipboard managers" question left. We probably want to implement the standard to some extent, how full IMHO depends on whether we break expectations in some app.