Clipboard support on Linux: A few hiccups.

[Laurent]

What are the reasons for NOT doing it like it's done in the original APIs?

Because it is not intuitive. I understand that we might not be able to do it differently, however from a user point of view this can be very confusing. For example, one has to understand that w1.setClipboardText(t1); w2.setClipboardText(t2); will result in t2 being stored in the clipboard, owned by w2. t1 is lost, it is not stored in w1.

The clipboard is a shared resource but since we make it member of windows, we can give the false impression that each window has its own clipboard data. If we do it this way, we must think about an API that reflects the behaviour better. Something like sf::Clipboard::setText(t1, w1); may be slightly better, for example. It emphasizes the clipboard, the data, and make the window argument less important, even though it remains mandatory.

A dedicated sf::Clipboard class can also be a better option to avoid bloating sf::Window with a lot of clipboard-specific functions. We could then think about a system to allow pluging "handlers" for MIME types other than plain text, this way sfml-graphics could add (in an unintrusive way) support for image formats, for example. Users can also support more specific types.

sf::Clipboard::getData<sf::Image>();
--> would call sf::Image clipboardHandler(const char*);

Just an idea.

[Tank]

I haven't thought about conversions yet, but having functions in sf::Clipboard is also what I'd prefer as well.

[wintertime]

If I may say so, I think that its natural to have this associated with the window and adding hacks with global variables to avoid that would not be worth it.
Though if you need to have it more complicated, just add a proxy Clipboard class, require the window reference in its constructor and forward method calls to the window.

[Aster]

Can someone suggest an internal design for a dedicated sf::Clipboard class/namespace, or static member functions?

Possibly we could have a hidden pointer that contains the last created window (even though this is a horrible, horrible hack), but that could bring in the issue of volatility. Some windows are created and then deleted over short periods of time (a confirmation dialog, for example), and that would result in the clipboard's contents disappearing.
This approach would require a window to be open for the clipboard to be used, thus not making it suitable for console applications.

If we went for a hidden window, we could store it in the sf::Clipboard namespace (there's no way to make this clean without globals, imo), and have its events processed every time sf::WindowImpl::processEvents is called? We could then provide overloads depending on the module. We'd have to somehow initialize the window, though. This approach would allow for the clipboard to be used even if the application hasn't opened any windows, although it would fail if a display server is not running.

EDIT: I started writing this before I read wintertime's post

[Laurent]

The problem with the hidden window is that it would have to be global. And we all know how dangerous global windows may be.

My point of view has slightly changed, and although I'm still not 100% satisfied with it, I guess such an API would be the best compromise:

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

[FRex]

This "design" flew out after 1.6 but if you really need a "good" window that is getting its' events handled and really don't want to put garbage in the sf::Window API then there is the possibility of doing it like sf::Input class was done in 1.6:

////////////////////////////////////////////////////////////
/// Get the input manager of the window
///
/// \return Reference to the input
///
////////////////////////////////////////////////////////////
const Input& GetInput() const;

[Laurent]

This would still feel like there's a separate clipboard for each window (as there was a separate input manager for each of them).

[FRex]

Yeah, I know, and it's less than ideal (actually it's kind of weird/stupid) because of that but it fixes both of the problems:
1. It communicates (more or less) that you must take responsibility for handling events of the window whose clipboard you want to use.
2. The cost in sf::Window API is constant - 1 function (getClipboard).

This is not a silver bullet BTW, just a suggestion to get rid of the "it must be in sf::Window vs. it'll clutter the sf::Window API if we extend the clipboard later" problem, this way it can both be in sf::Window and not pollute its' API.

[Laurent]

I still prefer a sf::Clipboard interface that takes the "owner" window as an argument whenever you set new clipboard content.

[Ixrec]

1. It communicates (more or less) that you must take responsibility for handling events of the window whose clipboard you want to use.

If I remember correctly, the clipboard-related events are still an X11-specific implementation detail that we don't want users to know about, and the only inconvenient truth we do need them to know is that you must have a window to do clipboard operations.


For what it's worth, as an SFML user rather than a maintainer/contributer, I don't particularly care if these functions end up as sf::Window members or as sf::Clipboard members taking references to sf::Windows.  Both APIs look fairly trivial to use and not that hard to extend.  I see some good arguments in favor of the sf::Clipboard design that takes window handles, and if I had to pick one I'd probably go with that, but mostly I just want an agreement to be reached so that this feature doesn't go the way of others like complex text layout (tl;dr: "the only way to do it is ugly, so we won't do it at all").

(By the way, FRex, I know the worst of it was several posts ago, but try to be a little less hostile.  I agree with some of your accusations, but repeating them in unrelated threads like this only increases the chances of this feature going downhill too.)


One thing I wanted to ask in case I ever find a use for sf::Clipboard myself: Do any operating systems emit "copy requested" or "paste requested" events?  I feel like deciding whether ctrl+c or click & drag or right-click should trigger a copy operation is one of those religious choices I shouldn't make for the user, but so far I can't find any evidence that "copy" events actually exist outside of certain browser and application-specific APIs.  I assume there aren't any and I just have to deal with that, but it'd be nice to know for sure.

[Aster]

One thing I wanted to ask in case I ever find a use for sf::Clipboard myself: Do any operating systems emit "copy requested" or "paste requested" events?  I feel like deciding whether ctrl+c or click & drag or right-click should trigger a copy operation is one of those religious choices I shouldn't make for the user, but so far I can't find any evidence that "copy" events actually exist outside of certain browser and application-specific APIs.  I assume there aren't any and I just have to deal with that, but it'd be nice to know for sure.

No, I don't think they do. They do, however, emit Drag n' Drop events, (XDnD etc), but that's for another PR

[Tex Killer]

Wait, did I missunderstood what you guys said, or does the copied content vanishes once the Window is closed? That is completely unintuitive and awful. Many times I open something like a text file, copy a part of it, close the text file, then paste the copied text somewhere else. Sorry if I missunderstood the issue, but if I didn't, then that is f***ed up.

[Laurent]

does the copied content vanishes once the Window is closed?

On Linux, with X11, yes. That is probably the most annoying thing in the world. On Windows, no. But that's an interesting question, because then I wonder what's the meaning of the "owner window" on this OS if the clipboard content is still available after the window is closed.

[dabbertorres]

Wait, really? Hmm. There has got to be a way around it then, because it works just fine on my Linux setup. Though I wonder if the WM is running it's own clipboard then.

Out of curiousity, which selection is being used in the current clipboard branch?

[Aster]

does the copied content vanishes once the Window is closed?

On Linux, with X11, yes. That is probably the most annoying thing in the world. On Windows, no. But that's an interesting question, because then I wonder what's the meaning of the "owner window" on this OS if the clipboard content is still available after the window is closed.

That's why you need to call CloseClipboard or something.
On Linux, it makes perfect sense. The clipboard is decentralized, it's meant purely for client-to-client communication.

Wait, really? Hmm. There has got to be a way around it then, because it works just fine on my Linux setup. Though I wonder if the WM is running it's own clipboard then.

Out of curiousity, which selection is being used in the current clipboard branch?

We use the CLIPBOARD selection. You've probably noticed this phenomenon, but never associated it with closing a window.
Some clipboard managers will indeed take ownership of the clipboard once in a while to prevent its contents from being lost.