Clipboard support on Linux: A few hiccups.

[Aster]

Yes, sf::Clipboard::setString() would be nice, but it's pushing things a lot and seriously not worth the effort just because someone isn't happy with SFML's API being exactly the same as its competitors'.

GLFW indeed does it like that, but SDL doesn't.

You're right. The API doesn't require the user to specify a window. Well, it does, but not the public API.
I didn't look at the docs, to be honest, but SDL source (src/video/x11/SDL_x11clipboard.c) doesn't create a new window, it uses SDL's magical "hidden pointer" hackery (called _THIS in function arguments) to use the most recent window. So in a way, SDL's API is like GLFW's, except SDL has this hidden pointer stuff.

EDIT: Here's a gist of SDL_x11clipboard.c: https://gist.github.com/Mischa-Alff/f066e642015e7dbff729

However, the static functions are indeed tricky. What comes into my mind at first is using an invisible window. The problem with that is: Where and when do you handle X's clipboard events, in case an application requests the content? You can't process that in another window, because it won't receive them (if there's a way to do that, it would greatly help).

Without a lot of hacks and code, it's probably not possible to avoid using a member function in sf::Window.

Exactly, I seriously don't think it's worth it, and SFML doesn't have that SDL-like notoriety where it can afford to do evil hacks just because it can. (Plus, SFML's codebase is still somewhat readable.)

[Tank]

Thanks for pointing out the SDL thing. Sounds like side effects.

[Tank]

So, what's the opinion of you guys? Personally I think the member function is the cleanest solution.

[zsbzsb]

I agree, a member function would be the cleanest solution. Not to mention it gives us the ability to override it in the RenderWindow if we ever want to support the graphical side of the clipboard.

[Juhani]

I also favour the member function.

[Nexus]

Aster, thanks for the detailed explanation. I'll probably need to have a deeper look to understand all of that in detail.

I still don't like that the portable API is driven by the design of X11 -- one implementation on one specific system.

And the API does not make sense from a semantic standpoint, users not being familiar with X11 won't expect the clipboard to be associated with a window. Other than Juhani, I don't think we should prematurely exclude applications that access the clipboard but not the window. Why is a console application not allowed to use a clipboard?

Additionally, clipboard-related functionality is not gathered in one place if we add functions to the window. What if we decide to extend the clipboard API in the future, e.g. by supporting more MIME types? We would then have to further bloat sf::Window.

By the way, SDL is not the only library with such a design. Qt, Android, Java AWT, the .NET framework are further examples that provide dedicated classes for clipboard access.

[Aster]

And the API does not make sense from a semantic standpoint, users not being familiar with X11 won't expect the clipboard to be associated with a window. Other than Juhani, I don't think we should prematurely exclude applications that access the clipboard but not the window. Why is a console application not allowed to use a clipboard?

SDL and GLFW do this, so does Qt. You can't use the clipboard with those libraries without opening a window, first.

Additionally, clipboard-related functionality is not gathered in one place if we add functions to the window. What if we decide to extend the clipboard API in the future, e.g. by supporting more MIME types? We would then have to further bloat sf::Window.

Not really. If we had a clipboard class, we'd need to put it in a module that depends on all the other modules. We don't have any of those.
Also, for image support, we can have function overload in sf::RenderWindow when the time comes. Again, SDL and GLFW offer text-only interfaces to the clipboard, and nobody is complaining, so image support would really be a courtesy.

By the way, SDL is not the only library with such a design. Qt, Android, Java AWT, the .NET framework are further examples that provide dedicated classes for clipboard access.

SDL does not provide a clipboard class. SDL requires a window to access the clipboard, and the clipboard is part of the window struct/module.
I'm currently working on Android support. The API for clipboard stuff is decent enough. JNI breaks it, though.
Qt does have a clipboard class, but it's owned by a QApplication, which contains... a window!
Regarding Java AWT, I don't use Java, and I'm not going to just to check this, but it probably claims the clipboard is unavailable on Linux if you have no window open.

By the way: Comparing things to Qt is unfair, imo. Qt is a huge library that has existed for ages, its scope is completely different to the one of SFML. I don't think SFML's goal is to become as heavy as Qt is.

All that aside: Most libraries require a window to use the clipboard. The current API isn't evil, it's not different. It's much cleaner internally than alternatives. If you can find a cleaner way to do this, then I'm all ears.

[Laurent]

Correct me if I'm wrong, but although SDL and Qt require a window to have clipboard support, this doesn't appear in the public API, this is just an implementation detail. I'm totally ok if SFML does the same. What I'm against is to expose this detail in the public API.

[Aster]

Correct me if I'm wrong, but although SDL and Qt require a window to have clipboard support, this doesn't appear in the public API, this is just an implementation detail. I'm totally ok if SFML does the same. What I'm against is to expose this detail in the public API.

It does appear in the API for Qt (QApplication::clipboard()), but it doesn't appear in the API for SDL, you're right.
However, SDL is written in C and can take advantage of the fact that C doesn't have OOP (or any strict "this code is ridiculous" rules), so hidden pointers and whatnot are completely fine.

If you can find a way to do this in C++ while keeping the code clean, then yeah, it's a viable solution.
I just want to avoid inserting (large) hacks into the SFML codebase just for the sake of clipboard support. It is a minor (albeit somewhat important) feature, and changing the way everything is done just so that we can have a cleaner clipboard API seems like overkill to me. (But if someone's up for it, be my guest  )

[Laurent]

It does appear in the API for Qt (QApplication::clipboard())

QApplication is not a window. You can have your QApplication without any window.

However, SDL is written in C and can take advantage of the fact that C doesn't have OOP (or any strict "this code is ridiculous" rules), so hidden pointers and whatnot are completely fine.

This is not a language nor paradigm issue, it's pure design. In C you can do SDL_GetClipboardText() or SDL_GetClipboardText(const SDL_Window*). SDL does the former, the clipboard is not linked to a window.

If you can find a way to do this in C++ while keeping the code clean, then yeah, it's a viable solution.

I don't care if the X11 implementation is ugly. Nobody cares, only the maintainer(s), and on the other side the thousands of users are happy.

[FRex]

I don't care if the X11 implementation is ugly. Nobody cares, only the maintainer(s), and on the other side the thousands of users are happy.

Simply sticking a global std::vector to keep track of all X11 Window Impl instances will do, especially since you forbid everyone from creating windows at global scope already so there won't be issues with the unspecified order of construction and destruction of things.

[Juhani]

And the API does not make sense from a semantic standpoint, users not being familiar with X11 won't expect the clipboard to be associated with a window. Other than Juhani, I don't think we should prematurely exclude applications that access the clipboard but not the window. Why is a console application not allowed to use a clipboard?

What use cases could a console application have for the clipboard? I can't think of any. I still claim that an app needs no clipboard access if the user isn't copy/pasting, and the user can't copy/paste if there isn't a window. How would the user control the clipboard from a console app, anyway? Type in a command?

Additionally, clipboard-related functionality is not gathered in one place if we add functions to the window. What if we decide to extend the clipboard API in the future, e.g. by supporting more MIME types? We would then have to further bloat sf::Window.

This brings to my mind Guru of the Week #84, where Herb Sutter states that the most OO way to write methods in C++ is making non-member non-friend functions.
So, if we were to follow his advice we would make the clipboard interface exactly identical to GLFW, even a global function taking a window as a parameter.

[Aster]

What use cases could a console application have for the clipboard? I can't think of any. I still claim that an app needs no clipboard access if the user isn't copy/pasting, and the user can't copy/paste if there isn't a window. How would the user control the clipboard from a console app, anyway? Type in a command?

xclip.

This brings to my mind Guru of the Week #84, where Herb Sutter states that the most OO way to write methods in C++ is making non-member non-friend functions.
So, if we were to follow his advice we would make the clipboard interface exactly identical to GLFW, even a global function taking a window as a parameter.

And if we followed XKCD, SFML would be a Python library.

[FRex]

So, if we were to follow his advice we would make the clipboard interface exactly identical to GLFW, even a global function taking a window as a parameter.

And we should follow that extreme, pipe dream like advice that'd differentiate us from any popular C++ library ever (including the standard library) and make our API look almost 100% like the OO C APIs with the big bonus of RAII (except that our API, being C++, wouldn't be immediately useful from 5 or so languages automagically).. why exactly?

[Tank]

Please keep in mind that Windows' SetClipboardData requires the current window to be the owner of the clipboard, which can be acquired by calling OpenClipboard, which (drumroll) requires a window handle (if you give it NULL, the active one is used).

So it's not different from X. And if you think about it, X's implementation is not even bad.