Clipboard support on Linux: A few hiccups.

[eXpl0it3r]

So what is the status of this feature and discussion?
The PR certainly needs rebasing and most likely adjusting.
Let's take a look at it with fresh eyes and keep the discussion objective and less hostile.

[Laurent]

I'll try to sum up the current status:

- The PR needs more testing, for technical validation
- We all agree that getting and setting clipboard data must be tied to a sf::Window
- We all agree that only text data is relevant -- let's keep image data for later

About the API, I'm still in favor of

sf::Clipboard::setData(string, window);
string = sf::Clipboard::getData(window);

Instead of

window.setClipboardData(string);
string = window.getClipboardData();

Technically it's completely equivalent, but I prefer this design because:
1. it emphasizes the clipboard, then the data; the window, while still being mandatory, is just an argument
2. it doesn't give the false impression that each window has different clipboard data; instead it focuses on the global nature of this data
3. instead of adding more and more functions to the sf::Window class, this new functionality is kept separated in its own class, which makes maintenance and evolution easier

I can live with the other implementation though, if more people prefer it, or if technical limitations make it the only possible design.

[Ixrec]

Personally, I think it would make more sense if "window" was the first argument in both setData and getData.  Otherwise, that all sounds right to me.

[Gambit]

sf::Clipboard::setData(string, window);
string = sf::Clipboard::getData(window);

...
2. it doesn't give the false impression that each window has different clipboard data; instead it focuses on the global nature of this data

Huh? If you have to use the window at all, to me, it makes it sounds like the clipboard data is set per window.

[Hiura]

We all agree that getting and setting clipboard data must be tied to a sf::Window

Not quite all.

Is it because of a limitation/design choice of the Linux/Windows API? Because on OS X clipboard (a.k.a pasteboard) are not tight to a window but the application directly.

I guess I'll find a way around that if we decide to stick to your proposition (like a comment in the doc explaining that the window doesn't matter on OS X).

In any case, the sf::Clipboard version sounds better. But I disagree with Ixrec: for consistency with sf::Mouse:: setPosition(), the window parameter should be the second one.

Also, what do you think of setString/getString instead of setData/getData? It would be easier later to add set/getData for images (png, jpeg, pdf, ...) or any other kind of data. And it would be close to sf::Text API too (if relevant).

[Laurent]

Huh? If you have to use the window at all, to me, it makes it sounds like the clipboard data is set per window.

It is less less less less obvious in

std::string sf::Clipboard::getString(sf::Window& owner);

... where the window is just an argument which can be named so that any confusion is avoided, than in

std::string sf::Window::getClipboardString();

... where the window is the instance on which you call the function

Also, what do you think of setString/getString instead of setData/getData?

I don't know. Since we don't know the encoding (?) we should make it look like it's raw data rather than an encoded string.

[Gambit]

Sorry I'm still lost. Is clipboard data stored per window? I mean, if I set the clipboard data in my application, can I then paste it into notepad or whatever? If the data isnt stored per window, why does the window need to be passed?

[Ixrec]

Sorry I'm still lost. Is clipboard data stored per window? I mean, if I set the clipboard data in my application, can I then paste it into notepad or whatever? If the data isnt stored per window, why does the window need to be passed?

The earlier pages of the thread cover this in exhaustive detail, but if I remember everything correctly, basically the X11 and Windows clipboard APIs require that a particular window is involved when interacting with the clipboard (Mac OS doesn't require one, but obviously we want a cross-platform interface).  I forget if it served any particular purpose on Windows, but in X11 the clipboard is apparently something that gets passed around between windows, and once you acquire it you have to start listening for other applications' clipboard requests so you can pass it on to them as needed (yes, it's very strange).  As far as I can recall, there is no such thing as per-window clipboard data on any of these systems.

At least in my opinion, getClipboard(window) is a sensible way to make the API reflect the unfortunate truth that you need a window to talk to the clipboard even though the clipboard is a global object.  That and it's nice to have clipboard methods not be part of the Window class.

[Gambit]

Thanks that makes sense. In that case, I'll +1 having the clipboard stuff be its own interface.

[Aster]

It seems that the API people want is sf::Clipboard::set(string, window). How should this be implemented in a way that the X11 window can properly respond to selection related events?

[Hiura]

This window things makes me a bit uneasy: when I look at Qt doc or Wx doc, none use a window in the API, and so does SDL. So if SFML choose to be different, that's perfectly fine with me, but we better have strong arguments. The only one I could find -- sorry if I missed some -- in the previous pages was only to simplify the implementation, which is not a great argument IMO.

I had a look at OpenClipboard on msdn and apparently the window parameter is optional (*).

It seems that only X11 requires a window. Is it different with XCB? (It's getting late and I have exams to prepare so I let the linux expert among you deliberate on that.  )

Also, what do you think of setString/getString instead of setData/getData?

I don't know. Since we don't know the encoding (?) we should make it look like it's raw data rather than an encoded string.

I haven't made my mind on that, but requiring an ANSI string from the user for the first version should be alright. Later, we can add MIME or UTI later and use them to choose the encoding, I guess.


(*) be aware that EmptyClipboard should not be called in that case.

[Nexus]

Don't forget Android and iOS -- they seem to not require a window handle, either.

So far, it's really
"we have to reflect the underlying implementation details in the API"
vs.
"we have to make the API as easy as possible to use, taking into account a more complicated implementation"...

[Tank]

Hiura, X11 is the protocol, Xlib and XCB the libraries that talk X11. So yes, same with XCB.

[Tank]

Regarding the API: In case you want to drop the window parameter, you will have to maintain a global window array. And you also have to make sure that the selection is owned by an existing window.

I don't like global arrays and the fact that sf::Window itself would be dependent on it.

I don't see issues with providing and optionally ignoring the parameter. We just can't make a good API that pleases all platforms, the differences are too elementary.

I vote for keeping the internals clean by avoiding another global state object (such things had already blown up programs in the past) and exposing the window implementation detail to the API.

[Laurent]

Yes, this has already been discussed in details in the previous pages, we should now try to move forward

Regarding the implementation: can this somehow be handled entirely on the sf::Clipboard(Impl) side, like for example with a thread, Window::getSystemHandle() and a separate event loop, or would sf::Clipboard have to be a front-end to private functions of sf::Window?