Clipboard support on Linux: A few hiccups.

[Laurent]

That's why you need to call CloseClipboard or something.

And how does this explains that the content of the clipboard is still available after the window is closed?

[Aster]

That's why you need to call CloseClipboard or something.

And how does this explains that the content of the clipboard is still available after the window is closed?

After a bit of reading..

Although MSDN doesn't specify how clipboard ownership works, it does specify that the clipboard can contain data even if it has no owner. I couldn't find anything on the internals of this, but ownership of the clipboard is given when EmptyClipboard is called, and that's pretty much it. You lost it when EmptyClipboard is called by another window.

There are GetClipboardOwner functions, but I'm not sure what they're for.

[Juhani]

If SetClipboardData succeeds, the system owns the object identified by the hMem parameter.

[Laurent]

So, if I understand correctly, on Windows, you can't set clipboard data if it's not owned by a window, but if the owner window disappears then the clipboard data remains valid? This doesn't make any sense

[Tank]

Yeah, EmptyClipboard would fail if you called it without being the owner. Not the first time that the WinAPI is confusing.

[Mario]

So, if I understand correctly, on Windows, you can't set clipboard data if it's not owned by a window, but if the owner window disappears then the clipboard data remains valid? This doesn't make any sense

No. You'll essentially have to open/lock the clipboard to get write access. You then pass in an object, which is overtaken by the system (so you're no longer allowed to directly modify or free it). You close the clipboard and you're done. You don't have to handle ownership or anything and you don't have to track your data (if you don't want to). Ownership here is basically just about who's allowed to free some (shared) memory.

However, there's some way to intercept clipboard requests to pass more advanced/custom data (e.g. not just plain text), which is something you might have seen done by Microsoft Office. For example, if you copy lots of text and close Word, it will ask you whether you'd like to keep your clipboard contents (since it's then passing off ownership).

[Aster]

Yeah, EmptyClipboard would fail if you called it without being the owner. Not the first time that the WinAPI is confusing.

EmptyClipboard sets the owner. As Juhani said, the contents of the clipboard are owned by the system, not the window, when SetClipboardData is called, which is why you don't delete them during cleanup.

[Aster]

So.. no conclusion?
Now that we've been through the internals, is the current API suitable?

[Laurent]

I proposed an alternative API, and although nobody seemed to be against it, there was no explicit comment about it, so... I'm like you, waiting.

[Nexus]

How would the implementation look on other systems -- OS X, iOS, Android?

Does the use of XCB instead of raw X11 change anything?

[Aster]

How would the implementation look on other systems -- OS X, iOS, Android?

Nor OSX, nor Android require a window handle to use the clipboard as far as I know.
No clue for iOS.

Does the use of XCB instead of raw X11 change anything?

No.

[Juhani]

The current API (member function) is fine with me. Concerning Laurent's concern of possibly giving a false impression that each window would store its own clipboard data, I think it could be solved by just calling the member functions more appropriately: seizeClipboard(sf::String) and String readClipboard(), to reflect that the clipboard isn't a sf::Window field.
But if there are good reasons for a non-member approach, then what Laurent suggested is also fine with me:

class Clipboard
{
    static data get(window?);
    static void set(data, window);
}
 

[zsbzsb]

I have nothing against either a member function or a static function (but I still think a member function is best). I would just have an issue with making a dedicated class like sf::Clipboard that would presumably end up in the system module. What happens if we want to support more MIME types such as images? Then we would have to have the system module rely on the graphics module for the sf::Image type which would then lead to a circular dependency issue. If we keep it as part of the window class then we can provide overloads of the get/setClipboard function to support images within the clipboard.

[Laurent]

but I still think a member function is best

Why?

What happens if we want to support more MIME types such as images?

The system must be flexible enough to support external handlers for other MIME types. So the base implementation should only deal with raw data (text) and provide a way to plug other conversion handlers that would work on top of this raw data.

[Nexus]

I'm definitely in favor of a sf::Clipboard class. With it, there have been two proposals:

static void copyText(sf::Window& window, const sf::String& text);
static sf::String pasteText(sf::Window& window);

or

static void copyText(const sf::String& text);
static sf::String pasteText();

It seems like the main argument for the first one is that it simplifies the implementation and does not require a dummy window when there is none, while the second one simplifies the usage and does not pull implementation details to the API. It's also not clear what the window parameter would do on systems that have a truly global clipboard (it would obviously do nothing, but requiring it nonetheless is user-unfriendly) and how the semantics of the window could be explained in a portable way.

By the way, instead of generic "setText" and "getText" methods, I would probably call them "copy" and "paste" or "copyText" and "pasteText". Or maybe "string" instead of "text", to make sure we refer to sf::String and not sf::Text.