New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add wlr-data-control-unstable-v1 #25

Merged
merged 1 commit into from Jan 7, 2019

Conversation

Projects
None yet
5 participants
@emersion
Copy link
Member

emersion commented Jul 24, 2018

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 emersion force-pushed the emersion:data-control branch 2 times, most recently from d2506d1 to c1680b7 Jul 24, 2018

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Jul 25, 2018

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 emersion referenced this pull request Jul 28, 2018

Merged

Implement wlr-gamma-control-unstable-v1 #1157

2 of 2 tasks complete

@andyholmes andyholmes referenced this pull request Nov 17, 2018

Closed

Multi-DPI Support #335

@emersion emersion force-pushed the emersion:data-control branch from c1680b7 to 7fc9c55 Dec 5, 2018

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Dec 5, 2018

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.

@emersion emersion force-pushed the emersion:data-control branch 2 times, most recently from 14d17d9 to 746b434 Dec 5, 2018

</event>
</interface>

<interface name="zwlr_data_control_offer_v1" version="1">

This comment has been minimized.

@bugaevc

bugaevc Dec 5, 2018

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?

This comment has been minimized.

@ascent12

ascent12 Dec 5, 2018

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?

This comment has been minimized.

@bugaevc

bugaevc Dec 5, 2018

  • 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

This comment has been minimized.

@emersion

emersion Dec 5, 2018

Member

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.

This comment has been minimized.

@emersion

emersion Dec 5, 2018

Member

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

This comment has been minimized.

@ascent12

ascent12 Dec 5, 2018

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

This comment has been minimized.

Copy link

bugaevc commented Dec 5, 2018

What about primary selection?

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Dec 5, 2018

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

This comment has been minimized.

Copy link

ascent12 commented Dec 5, 2018

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

This comment has been minimized.

Copy link
Member

emersion commented Dec 7, 2018

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.

@emersion emersion force-pushed the emersion:data-control branch from 746b434 to ef8b52e Dec 12, 2018

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 12, 2018

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 12, 2018

@bugaevc

This comment has been minimized.

Copy link

bugaevc commented Dec 12, 2018

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

This comment has been minimized.

Copy link
Member

emersion commented Dec 12, 2018

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

This comment has been minimized.

Copy link

bugaevc commented Dec 12, 2018

Ah, right, that makes sense

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 14, 2018

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 14, 2018

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 20, 2018

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 20, 2018

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 26, 2018

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 26, 2018

@emersion emersion force-pushed the emersion:data-control branch from ef8b52e to cdd0edd Dec 30, 2018

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 30, 2018

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 30, 2018

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 30, 2018

bugaevc added a commit to bugaevc/wl-clipboard that referenced this pull request Dec 30, 2018

@ammen99

This comment has been minimized.

Copy link
Member

ammen99 commented Jan 7, 2019

we should merge this?

@ddevault

This comment has been minimized.

Copy link
Member

ddevault commented Jan 7, 2019

ya

@ddevault ddevault merged commit 4ff1cda into swaywm:master Jan 7, 2019

1 check passed

builds.sr.ht: .build.yml builds.sr.ht job completed successfully
Details

@emersion emersion deleted the emersion:data-control branch Jan 7, 2019

@zetorian zetorian referenced this pull request Jan 22, 2019

Open

Support Wayland #53

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment