Messages

16

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 12, 2014, 11:38:19 pm »

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.

17

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 12, 2014, 09:11:29 pm »

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.

18

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 12, 2014, 06:08:17 pm »

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

19

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 12, 2014, 02:25:50 pm »

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

20

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 11, 2014, 10:07:57 pm »

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.

21

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 11, 2014, 09:49:17 pm »

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.

22

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 11, 2014, 09:41:10 pm »

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.

23

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 11, 2014, 08:48:02 pm »

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.

24

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 11, 2014, 02:14:19 pm »

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?

25

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 11, 2014, 10:35:03 am »

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.

26

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 10, 2014, 11:55:34 pm »

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.

27

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 10, 2014, 09:16:39 pm »

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  )

28

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 10, 2014, 08:27:51 pm »

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.

29

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 10, 2014, 10:28:00 am »

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.)

30

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 09, 2014, 10:33:52 pm »

What I meant is a sf::Clipboard::setText() function, sorry for not being clear. You say it takes time to set the clipboard's contents because one first has to get ownership of it, right? What I meant is that you don't immediately do that, but somewhere in the background. Is it not possible to get ownership of the window in a non-blocking way (i.e. asynchronously by requesting it and checking later whether we've already gotten it)?

Has somebody already measured how severe this delay is in practice?

I'm sorry for not being clear, too. Here's my attempt at being clear:

X11 has a thing called selections. There are three notable ones: PRIMARY, SECONDARY and CLIPBOARD. Most modern applications use the CLIPBOARD selection.

To obtain, or get the contents of the CLIPBOARD selection, you must request a conversion to the desired format to the X server, which forwards that request to whoever owns the clipboard. Then, whoever owns the clipboard checks if it's even possible to convert the selection to the requested format, and essentially responds directly to the requestor by sending them an event that contains information on the conversion as well as where to get the requested data. This response is usually very quick, so you can expect to receive it in less than one second and almost never miss it.

To set the contents of the CLIPBOARD selection, you must request ownership of the selection. This is immediate, as the X server does not wait for approval from the current owner to do this. You then update your cached contents of the clipboard, and you're done.

Actually, I lied. You're not done. You're the owner of the clipboard.
Once you own the clipboard, you need to respond to all incoming events requesting a conversion (remember what I mentioned about getting the contents? We're the ones doing the conversion now). This is the main reason for which the function can't be blocking. These events need to be processed often enough that the requestor doesn't lock up waiting for the CLIPBOARD selection's contents (Google Chrome tabs will do this). This is being done in the processEvent function as of writing this.

There are no issues with performance with the current implementation, just look at the benchmarks I did.

The API we're using is completely fine. SDL and GLFW use it, and nobody has ever complained. 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'.