Add wlr-data-control-unstable-v1

[emersion]

This is just a copy of wl_data_device_manager and its related interfaces, with drag-and-drop related stuff stripped out. The main difference is that the clipboard manager doesn't need to have keyboard focus to receive selection events.

I wonder if we need more than that in this protocol.

I intentionally left out primary selection for now, because it's easy to add but I want to make sure this design is good before doing so. Also some compositors don't support primary selection.

Fixes #20

[emersion]

Thoughts:

• Should we allow multiple managers to bind at the same time? This could prove useful if we want to allow e.g. one client to save previous selections and one xclip-like client at the same time.
• What information about the client setting the selection should we provide? This information won't always be available (some compositors can set custom selections like Sway used to do with the IPC, there are selections set by the clipboard manager itself and xwayland…). I'd go with title and app_id, if available.

[emersion]

Updated the protocol to improve the description, added an error and a "finished" event to the data control object (to let the compositor revoke access for a client).

Should we allow multiple managers to bind at the same time?

Yes, but this is an implementation detail.

What information about the client setting the selection should we provide?

It'll be easy to add these by bumping the protocol minor version. I prefer to wait until people actually need that.

[bugaevc]

Is there a reason why every new clipboard protocol has to ship its own offer/source types? Why not reuse wl_data_offer/wl_data_source?

[ascent12]

It would be a maintenance burden and leads to questions regarding protocol object versions.
If it's all in a single protocol, you just have your different objects have the same interface version. If you're dealing with types defined by other protocols (including the core wayland protocol), who knows what version you're supposed to return?

[bugaevc]

• I agree that this can be a problem in general
• wl_buffer is supposed to be used this way, which is why it's always on version 1
• In this case, wl_data_offer/wl_data_source v1 is exactly what you need wrt d'n'd stuff
• This way it is a maintenance burden (for me in wl-clipboard, at least) to support many (just two so far, but it's going to be four in the foreseeable future...) semantically equivalent but incompatible copies of offer/source types

[emersion]

In this case, wl_data_offer/wl_data_source v1 is exactly what you need wrt d'n'd stuff

Objects in Wayland inherit the version of their parent object. You can't do anything about it, it's hardcoded in the Wayland design.

This means if you have wlr_data_control_offer v10, it will only be able to create v10 objects. You won't be able to create e.g. wl_data_offer v1 objects.

[emersion]

wl_buffer is an exception that works only because it's frozen. It makes it impossible to ever add anything to its interface.

[ascent12]

wl_buffer is supposed to be used this way, which is why it's always on version 1

wl_buffer is special. It's not a good example when bringing up wayland types.

In this case, wl_data_offer/wl_data_source v1 is exactly what you need wrt d'n'd stuff

That's not forwards compatible. What happens when someone bumps that to version 4 and adds something new?
Not to mention, you're now going to have clients that may need to deal with multiple versions of the same protocol object, which in itself seems extremely annoying.

This way it is a maintenance burden (for me in wl-clipboard, at least) to support many (just two so far, but it's going to be four in the foreseeable future...) semantically equivalent but incompatible copies of offer/source types

It's just the nature of how wayland is designed. It's very boilerplatey.

[bugaevc]

What about primary selection?

[emersion]

What about primary selection?

Deliberately left out. Will add later if this design works (should be possible without breaking the API).

There are also issues with compositors not supporting primary selection. We should make sure it works well in this case.

[ascent12]

There are also issues with compositors not supporting primary selection. We should make sure it works well in this case.

Would something along the lines of this work?

<enum name="data_device_type">
    <entry name="clipboard" value="0"/>
    <entry name="primary" value="1"/>
</enum>

<event name="data_device">
    <description>
        Advertisement of data device supported.
    </description>
    <arg name="device" enum="data_device_type"/>
</event>

And adding this enum to the get_data_control.

[emersion]

Protocol implementation: swaywm/wlroots#1423

Maybe we should rename zwlr_data_control_v1 to zwlr_data_control_device_v1 for consistency.

@ascent12 Yeah, although the regular selection should always be supported.

[bugaevc]

What information about the client setting the selection should we provide? This information won't always be available (some compositors can set custom selections like Sway used to do with the IPC, there are selections set by the clipboard manager itself and xwayland…). I'd go with title and app_id, if available.

Perhaps you'd want to add nullable title and app_id to the selection event while it's not too late

[emersion]

Perhaps you'd want to add nullable title and app_id to the selection event while it's not too late

Nah, I'd prefer to add these as events in the offer interface.

[bugaevc]

Ah, right, that makes sense

[ammen99]

we should merge this?

[ddevault]

ya