Clipboard and open with default application support

[Jesper Juhl]

That sounds reasonable to me (the paste event thing).
But what if the user wants to stuff something into the clipboard? Stuff it into PRIMARY? CLIPBOARD? Both? Should the user be able to choose?

[zsbzsb]

For reference, Aster (Mischa-Alff) was working on clipboard support. His repository is here.

[Juhani]

That sounds reasonable to me (the paste event thing).
But what if the user wants to stuff something into the clipboard? Stuff it into PRIMARY? CLIPBOARD? Both? Should the user be able to choose?

The best service for the user would be letting him choose which clipboard to overwrite, which would normally be determined by key bindings: ctrl+c for CLIPBOARD and selection for PRIMARY. Always overwriting both clipboards would be an annoyance to the user, especially if he doesn't expect it.

[Ixrec]

The main problem with that is I don't think the PRIMARY/CLIPBOARD distinction applies to other platforms.  In particular, Windows only seems to have one clipboard period (the documentation I read even implied that you take ownership of the clipboard by emptying what's currently in it).  Mac OS seems to have a separate "pasteboard" for drag and drop content, but still only one pasteboard for the traditional copy/paste behavior we're interested in.  So I don't know if there is any sensible cross-platform interface that could expose this PRIMARY/CLIPBOARD distinction.

But does it even matter?  I've never felt the need to perform multiple copies and then multiple pastes, as opposed to multiple copy-pastes.  It's not like that enables anything that isn't already possible with copy-pastes through a single clipboard.  Is there any real need to support this use case, or is it just a neat trick that Linux offers but no one else cares about?

[Jesper Juhl]

As far as SFML goes I guess you can call it "a neat trick that noone cares about" - and I personally won't mind.
When it comes to actual usage, then I think you'll find that many *NIX users care about how their clipboards behave and expect certain things. I don't think I'm the only one to be accustumed to multiple clipboards.
But, as far as SFML goes, a clipboardPaste event that triggers no matter which clipboard you paste from would be just fine (IMHO).
And, if we want to let the user stuff something into the clipboard, then letting that just be into PRIMARY would work for most people (or maybe PRIMARY and also CLIPBOARD).
For what SFML is doing it's not hugely important, so if we just implement something basic it's likely to be good enough (at least for starters).

[Ixrec]

I guess we could simply have the setClipboard function take an optional sf::Clipboard::Implicit/Explicit parameter saying whether the user explicitly triggered this copy or not, then the platform-specific code can decide whether to do anything with that.

Perhaps more important is whether we should try to support data types other than simple text.  At the very least whatever API gets used should definitely allow for this extension, even if at first sf::Clipboard::Text and sf::Clipboard::Any (which returns the raw data) are the only supported data types.  In an ideal world the various kinds of image data different clipboards support could be passed directly to sf::Texture::loadFromMemory, but I have no idea how feasible that is (still don't have the time to investigate this stuff myself =( ).

[Nexus]

I don't know whether SFML should take care of all those Unix-specific clipboards. After all, it abstracts from operating systems and tries to show the same behavior on all platforms. I also think the "PRIMARY" clipboard with selection and middle mouse key is rather used within the same application, than between different applications.

So... why not simply provide the "CLIPBOARD" one with Ctrl+C and Ctrl+V, as it will be provided on other platforms?

[Juhani]

Using the CLIPBOARD would also allow adding support for PRIMARY later without changing the clipboard interface.

Concerning the suggested paste Event, it occurred to me that the user might want to bind the middle-mouse or ctrl+v to something else in a context where clipboard isn't needed (such as in a FPS game). Then SFML would be reading the clipboard needlessly to produce the paste Event (which would be ignored).

[select_this]

I'm not a fan of the middle mouse button clipboard, personally - I always disable it because I'm clumsy and often accidentally end up pasting stuff. I'd be happy with just ctrl-c ctrl-v if I ever needed clipboard functionality.

[Aster]

For reference, Aster (Mischa-Alff) was working on clipboard support. His repository is here.

I am indeed working on clipboard support. The link is here, rather. Win32 support is already implemented. Linux is a bit more complicated and I'd like to do it right instead of having some hacked together code. (By "a bit", I mean "Oh God my eyes are bleeding why did I ever commit to doing this?!")

We could handle all the Linux cut buffers/clipboard/selections etc, but honestly, it's not worth it. I'm settling on using X11 selections (or whatever they're called, it's late) because they work pretty much everywhere, and that's what everyone else uses.

I'd be a bit more enthusiastic about Linux support, but my ArchLinux drive died (after ten years of service), and I'm waiting for a new SSD to get delivered to move back to using Arch again. For what I've looked at so far, it might be worth having a clipboard event that's only handled internally, but I'll have to see how I should work with that.

The API is:

• sf::String sf::Window::getClipboard();
• void sf::Window::setClipboard(const sf::String&);

There's an example in examples/clipboard in case you want to test it out.

Also, on handling multiple MIME types, zsbzsb suggested we overload the function in sf::RenderWindow for image support. I'm still hesitant about this. If you want to use multiple MIME types in the clipboard, chances are what SFML will provide isn't enough, and you'll end up extending it yourself anyways.

Cheers.