Question: What should i use to make a clipboard manager?

[wiiznokes]

After looking the api for a while, it's still not clear to me what should i use.

I think what i need is the serve function. But how can i know when there are events to serve?

From what i understand, this is the process:

1. An app decide to copy data to clipboard
2. It notify the wayland compositor, with a list of tuple with source and mimetype
3. The clipboard manager should be able to get notify here. It will clone the mimetype and the content of the source
4. The clipboard manager create a copy event, to become the source of the data
5. if there is a paste, the clipboard manager will be used as a source

is this correct?

Also, another thing that triggered me is

Primary

The “primary” clipboard.

Working with the “primary” clipboard requires the compositor to support the data-control protocol of version 2 or above.

But i'm not seeing any v2 here

Thank is advance for any responce

[YaLTeR]

Hey, what you want for a clipboard manager is something like wl-paste -w from wl-clipboard which keeps notifying you of new clipboard contents as they change. Unfortunately, I have not yet implemented this in wl-clipboard-rs.

But i'm not seeing any v2 here

Note the:

[wiiznokes]

Note the:

Thanks, i'm not very familiar with wayland but i hope to learn. This is a reason why i want to make a clipboard manager.

Good to know for wl-clipboard, but using C is not really an option for me. I would rather try to enhance this crate.

Is the process I listed above is correct ? This will help me to get in the right direction

[YaLTeR]

Thanks, i'm not very familiar with wayland but i hope to learn.

So if you take a look in wayland-info for example, you'll see something like:

interface: 'zwlr_data_control_manager_v1',               version:  2

This version on the right is the v2 that is needed for the primary clipboard. Increasing that version must be backwards-compatible to an extent.

There's also the literal _v1 in the name of the interface. That's for when the protocol needs to make a backwards-incompatible change, then it will bump that "version" (effectively it will be a completely different protocol then) and reset the number version back to 1.

Is the process I listed above is correct ?

Yeah, that is more or less correct.