Clipboard support on Linux: A few hiccups.

[Nexus]

Let's argument from the point of view of a user, not a developer. This should be the main approach when designing any API, because that's what it is: an interface for the user.

As a user, I don't know that a window is required to keep the clipboard, and I'm not interested in all that ownership stuff. It's something the library should take care of for me, otherwise I could use low-level libraries directly.

First, when looking up the functionality in the SFML documentation, I would not expect the clipboard functionality to reside in a class that is responsible of displaying a window. Continuing with the usage, I don't want to have a window around every time I access the clipboard. Since clipboards have global semantics (even if they're internally accessed through one specific window), I would like to deal with them accordingly. Additionally, there are cases where I have no window at all, or where I have multiple ones and need to pick one arbitrarily.

A sf::Clipboard class doesn't complicate the implementation a lot. As soon as a window is around, we can use that one. In the X11 implementation, there is already a global list of windows, which is required for the focus requests. It could be slightly more implementation effort to create a dummy window when there is no window -- but don't forget, this is an additional feature you wouldn't even have with pure sf::Window member functions.

If necessary, things can still be implemented in the sf::Window class (or its backends), and the sf::Clipboard class could either access them directly, or via friend through sf::Window.

[Tank]

How do you process the events of the dummy window? Is it possible to receive events for all windows that were created by the process?

Regarding the argument that you want to use the clipboard in a non-GUI program: it's not possible, and that's the reason why you are trying to work around that fact by hiding the window stuff. I find it quite funny, that for a public API, you want to suggest the user that the clipboard is independent, whereas at least Windows and X11 designed it differently, and you follow that internally, i.e.: "The clipboard is global and independent, but internally it's not, so we teach you wrong things." ;-)

That's actually rewriting how that stuff works. And besides of that, I'm really afraid that there are use cases that we don't see yet.

There can still be sf::Clipboard, that's not the issue.

[Laurent]

On Windows, it's not clear what the optional HWND argument does, and I think that most people don't use it.

[Aster]

On Windows, it's not clear what the optional HWND argument does, and I think that most people don't use it.

I booted into Windows just to test this.
If you read the docs ( http://msdn.microsoft.com/en-us/library/windows/desktop/ms649048(v=vs.85).aspx ), they clearly state that you can't set the clipboard if the hWndNewOwner is set to NULL. However, you can still get the contents, because you don't need to have ownership of the clipboard to get the contents.

In case you did read the docs: another user did comment (on the docs page, once again), saying that using NULL worked for them. I think we shouldn't go by what testing gives us, but we should follow the official documentation because it gives us what behavior to expect, and not the behavior some machines might have.

[Tank]

I'd like to underline that, in bold and red text: Just because people don't use something and things accidentally work shouldn't legitimate doing things that might brake.

The docs are very clear: NULL will make EmptyClipboard fail, and as Aster correctly stated, it's required for setting the clipboard data.

Sadly enough things like these are the reason why concepts like the clipboard are widely misunderstood and used wrong, programmatically-wise of course (not much you can do wrong with Ctrl+C and Ctrl+V ).

[Laurent]

I know someone who will agree with me: never trust the MSDN. Their documentation is often misleading, confusing, or even wrong.

So yes, I've read the doc and the contradicting comment, as well as a few tutorials / implementations. The result is my comment: we don't really know how it behaves...

[Aster]

The result is my comment: we don't really know how it behaves...

So why play around with undefined behavior when we have the option to have nicely defined behavior that works 100% of the time?

[Tex Killer]

Sure, use a window handler on Windows too, but I believe that is an implementation detail. Why should it affect the API? What is so bad about creating a dummy window if there is no Window already created?

[Aster]

Sure, use a window handler on Windows too, but I believe that is an implementation detail. Why should it affect the API? What is so bad about creating a dummy window if there is no Window already created?

It affects the API because doing it any different is a pain. Other libraries have the same API, so saying it's "unintuitive" is bullshit. The hacks required to do it differently are also horrible hacks that will ruin the codebase. Regarding Laurent's "nobody cares except for the maintainer": He's just saying that because he won't be the one who will have to dodge that stuff when it becomes an issue.

Having a hidden pointer like SDL does is definitely not a solution. It's dirty and a pain in the ass.
What FRex said (about the global std::vector of window handles) is absolutely ridiculous.

It's been a week now, and there hasn't been any agreement on this, so here's what I think:
The API is fine how it is, and the only reasons people are arguing against it are:

• They haven't done any research and thus aren't aware of some of the limitations provided by the underlying APIs used
• They won't be the ones maintaining this so they really don't care about how it looks in the codebase.
• They just want to argue about something

Yes, I'm being an asshole in this post. I'm tired of repeating myself, and unless one of you can find a better solution, please stop wasting the lifecycle of my keyboard.

[FRex]

Having a hidden pointer like SDL does is definitely not a solution. It's dirty and a pain in the ass.
What FRex said (about the global std::vector of window handles) is absolutely ridiculous.

You are absolutely ridiculous, what I said is so true that SFML actually already has (as Nexus pointed out) internal global std::vector of all X11 Impl instances (unprotected by mutex, as I said it could be, too):
https://github.com/SFML/SFML/blob/master/src/SFML/Window/Unix/WindowImplX11.cpp#L59
Somehow this (and all the other hidden globals and hacks in SFML) has not "ruined the codebase" as you claim.
Also, stop with the pointless bashing of C and SDL (and now SFML team) in every second post*.

*You can of course bash anything for right reasons, ie. bash SFML for the analysis paralysis (that you are contributing to now) or the obnoxious amount of useless comments in the source code.

[Aster]

Having a hidden pointer like SDL does is definitely not a solution. It's dirty and a pain in the ass.
What FRex said (about the global std::vector of window handles) is absolutely ridiculous.

You are absolutely ridiculous, what I said is so true that SFML actually already has (as Nexus pointed out) internal global std::vector of all X11 Impl instances (unprotected by mutex, as I said it could be, too):
https://github.com/SFML/SFML/blob/master/src/SFML/Window/Unix/WindowImplX11.cpp#L59
Somehow this (and all the other hidden globals and hacks in SFML) has not "ruined the codebase" as you claim.

So it does. I didn't know this. Maybe someone could have mentioned this several days ago, when I first said that adding a hidden pointer just for clipboard support was a bad idea.
To be clear, I find adding a std::vector of window handles just for the clipboard ridiculous. I didn't insult you, I claimed the idea was ridiculous.

Also, stop with the pointless bashing of C and SDL (and now SFML team) in every second post*.

I never bashed C nor SDL. It's your fault if you get offended when I say that the hidden pointer stuff is hacky, and that SDL has a hacky codebase due to its older age.

*You can of course bash anything for right reasons, ie. bash SFML for the analysis paralysis (that you are contributing to now)

I'm not contributing to "analysis paralysis", I'm angry at exactly that because I asked for critical contributions on my PR a week ago and received nothing but cruft.

or the obnoxious amount of useless comments in the source code.

I'm not sure why you'd criticize something for having too many comments. It prevents you from having to e.g look at the XCB docs every 20 seconds to find out what a function does. Or having to learn all about JNI just to add the equivalent of three lines of Java to the codebase.

[Aster]

Anyways, now that someone has brought up some development to this, should the std::vector of WindowImplX11 be used for a static clipboard function? What guarantees that the first window in this list has its events processed regularly? Should the same be done for Win32?

Is it worth it? It seems there were two arguments for a static function: clipboard access for console applications (not possible in any case, even with this method), and disassociation between the clipboard and the window (which makes no sense to me but whatever).
For the latter, it would still require at least one window to be open for the clipboard to function, and that sounds just as confusing and unintuitive for a first-time user as you claim a member function would be.

[Aster]

Actually, in the XCB branch, the allWindows vector is removed, and in master (as of writing this), the vector is only used for window focus (l498).

The PR uses the feature/xcb branch, so unless someone thinks this should be re-added for clipboard support, it's not there.

[eXpl0it3r]

Given the post, I might want to point out to you, that the XCB branch currently is behind master, meaning it doesn't have the feature window focus implemented, thus there's no global window list. Maybe it can be dropped with XCB, but I've no idea about X11 or XCB.

Did anyone ever ask the question: When do you need a static clipboard function? I'd say a console application which handles clipboard is quite a corner case (hence the dependence on a windows by the OS APIs). Are there other practical applications then?
I'm basically asking: Why should it be static? What's the ultimate gain? And is it worth the "loss"?

Clipboard is a UI/window specific thing. If you think it's not, well then that's your wrong assumption and not something everyone else has to follow now.

[Tank]

Can we please reduce the level of hatred and come back to a respectful and on-topic discussion? Thank you.

I still think that a Window-oriented function (either member or not) is what reflects the concept of clipboards programmatically-wise the most. Dropping that already requires to build work arounds, which is perhaps a good indicator of a problematic implementation.

@Laurent
But the MSDN is the only documentation we have, right from the creator. Just because 99% of tutorials don't care doesn't mean that we should not care. What if it's possible but they fix/harden the API in the future? Programs using SFML will silently break.

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

Oh, and regarding the globals: Please let's not introduce more of those time bombs. We can already see what problems context management makes, and IIRC the same happened with OpenAL in the past. I just don't like hacks.