Association with windows

[dhardy]

As mentioned in #3, X11 and Wayland essentially require a connection to the same seat/display/screen as a window, not to the window itself. Multi-window apps should therefore probably use their primary window's handle during construction of the Clipboard instance, then use that clipboard handle for all windows. This is a documentation issue.

Additionally, there are non-GUI clipboard tools. For:

• X11 these normally discover the screen from the DISPLAY env var; an option to specify this may be desirable
• Wayland, @vberger ?
• other platforms there is only a single seat anyway

We could therefore allow three constructors:

impl Clipboard {
    /// Construct for the default desktop
    pub fn new_default() -> _;
    /// Construct for the given desktop
    ///
    /// (On non-Linux platforms this is the same as `new_default`.)
    pub fn new_display(display_name: &str) -> _;
    /// Construct for the given window
    pub fn new<W: HasRawWindowHandle>(window: &W) -> _;
}

[elinorbgr]

Wayland, @vberger ?

Well, Wayland clipboard is tied to keyboard focus though. So a Wayland clipboard lib must use the same Wayland connection as the main app. Otherwise the compositor will not let it access the clipboard at all.

It is possible to do CLI cliboard managing apps for Wayland, but they require the use of a specific protocol extension which is not universally available and not meant to be used by general apps. So I don't think it would fit the scope of this crate to use it.

[hecrj]

The purpose of this crate is to offer an opinionated approach to clipboard access for window-based applications. This is why I called it window_clipboard.

I would consider any use case that does not involve a window out of scope, at least for the time being.

[dhardy]

Seems sensible I guess, even if 98% of the code doesn't care whether there is a window.