-
Hello all!
I've been spending the last few hours determined to get clipboard support working on Linux. You can check my progress here: https://github.com/Mischa-Alff/SFML/feature/clipboard
(NOTE: I won't push my current progress with support for X11 until it's finished. There's no point in making tiny little commits for every two lines of code)
I'm not 100% familiar with everything, so this is essentially all to the extend of my understanding. I might be wrong. God, I hope I'm wrong, but using X is a land of sadomasochism, and if I were wrong, it wouldn't be sadomasochism anymore.
The problems
- To receive the clipboard's contents, you must request ownership of the clipboard, request its contents, and then wait for an event containing the property that points to the contents of the clipboard. (This is apparently to prevent uselessly sending data around all the time)
- Once you've obtained ownership of the clipboard, you need to store its contents and send them to the next client who requests the data, until someone else requests ownership. (According to ICCCM sec. 2.6.1.3, you must request ownership to request contents, but not everyone follows ICCCM)
The potential solutions
Obviously, the only solution to the second one is to stick the selection sending code in the sf::WindowImplX11::processEvent function.
The solution to the first one is slightly more complex: Most software waits for a selection_notify_event in the getClipboard function, therefore driving the CPU up to 100% and sending all possible events to the event handler until it reaches a selection_*_event, then processing that event and returning the data sent in the event. The problem with this method is that it will completely block execution until it gets to the event it wants, which might be never.
References:
- ICCCM sec. 2.6.1.3: http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.1.3
- How GLFW does it (Look for "selection" and "clipboard"): https://github.com/glfw/glfw/blob/master/src/x11_window.c
I'm looking for recommendations as to how I should proceed on this, what would be best for the API, and what would be best for the codebase.
Please don't reply with your ideal vision of how the clipboard API should be, without any real advice. I'm trying to solve a problem that has been plaguing me for hours, and I would like a constructive discussion on how this could be solved.
Other than that, any help is appreciated and much needed. SFML needs clipboard support.
Thanks!
-
No suggestion, but a question: Will this be different/easier with XCB?
-
No suggestion, but a question: Will this be different/easier with XCB?
This is exactly the same procedure with XCB as with Xlib. The code only changes in a few places.
-
So from talking on IRC to help me understand this better. I would suggest the following model.
- SFML requests and holds ownership until another application requests it.
- When SFML has lost ownership and the user requests contents we return our cached version. (eliminates a busy wait that kills the CPU)
- When ownership is lost SFML will put a request out again to receive ownership again.
- Once ownership is received SFML will cache the current contents.
- When the user requests SFML to set the contents SFML will set its own internal cache and the actual content if it has ownership - if SFML doesn't have ownership it will set an internal flag to update the actual content next time it receives ownership.
-
After much more research and after a good night's sleep:
- You don't need to own the clipboard to request data. (You shouldn't own the clipboard to request data, since you'd be requesting the data from the owner: yourself)
- You need to own the clipboard to set its contents.
- If the owner of the clipboard no longer exists, the contents of the clipboard disappear.
- Ownership of the clipboard should be kept until someone else requests it. Then the burden of Mighty Clipboard Data Holder is lifted.
I'm pretty sure whoever designed this stuff was way over Ballmer Peak.
I'll add more as I go.
-
Yea, I think I read somewhere that on Linux no data is actually copied to the clipboard, so I imagine that when data is requested, a pointer is provided to it in the Mighty Clipboard Data Holder's memory.
So, to provide identical behavior on all platforms, SFML must itself keep a copy of the clipboard contents when it's owned by SFML on Linux.
-
Woo! It's working! It's finally working!
I'm just cleaning up my code and commenting it all, then I'll put it up on GitHub for testing.
-
Okay, I pushed my work to Git: https://github.com/Mischa-Alff/SFML/tree/feature/clipboard
Any criticism is appreciated.
Any testing is appreciated.
Be sure to checkout the feature/clipboard branch!
Cheers!
-
Hey Aster,
I reviewed your commits and mostly directly left comments at GitHub. I've got a question regarding the X11 implementation though.
As far as I understood, you enter an event loop in getClipboard and wait for the proper message from X with the requested information (selection owner notify). Isn't there a way to subscribe to general clipboard events, handle them in the main window's event loop by caching the content, and only work with that cache in getClipboard?
The current implementation adds a lot of redundant code and one issue I can see is that we have to take a lot of attention not to forget event stuff that's present in the "main" event loop.
The Win32 implementation and the example look good so far for me, nice work. :) (Except source code format etc, see comments @ GitHub.)
-
As far as I understood, you enter an event loop in getClipboard and wait for the proper message from X with the requested information (selection owner notify). Isn't there a way to subscribe to general clipboard events, handle them in the main window's event loop by caching the content, and only work with that cache in getClipboard?
Thanks for the review!
There's no such thing as "general clipboard events", you can only get these events if you request them. We could either request the contents on every call to processEvents (overhead), and have the function be semi-asynchronous (getClipboard will request that the cache is updated and return the cache, but not the new clipboard contents). The problem is that if the contents are requested too often, then you'll lock up whichever program owns the clipboard. (So if you're doing a test program at 5000FPS, X11 will probably die.)
The current implementation adds a lot of redundant code and one issue I can see is that we have to take a lot of attention not to forget event stuff that's present in the "main" event loop.
Yes! A solution is to modify WindowImplX11::processEvents() and give it the possibility to process all the events until a specific event. Or something like that. I'm new to contributing to SFML, so I didn't want to move too much code around.
-
Periodic requests don't sound like a solution indeed. God, X11 is the most annoying thing I've seen in my whole life.
Yes! A solution is to modify WindowImplX11::processEvents() and give it the possibility to process all the events until a specific event
That would definitely be a cleaner approach, i.e. the ability to wait for a specific event. This would require to have an internal event queue, though. I've almost implemented something like that for the key repeat workaround, but didn't have to in the end.
If nobody else has a good idea of working around the asynchronous clipboard stuff, I'd say let's give it a try. What do the other SFML team people say?
-
I think the least intrusive way would be to not hide the asynchronous nature of the clipboard.
- Have a RefreshClipboard method that just requests to set a variable in the class that handles events, if no request is already started.
- When the variable is set in that way the event handler requests the clipboard contents once, then remembers the status of the request.
- Then if more events are received later in the normal flow of the program they are additionally checked for if the clipboard contents are there, if yes it is remembered and so it can stop checking for more clipboard events.
- The user calls some GetClipboard method, this can return either "not ready" so that the user can check on next frame again, or it can give access to the data when its there.
That way no events need to be discarded or hold back and the program can continue without getting unresponsive from delays.
Maybe the 2 methods could be even combined and rerequests ignored until the data is there, if that looks like its easier to use.
On other OS it could just give success at first try if thats possible there.
-
If you want to keep the asynchronous nature (which is only asynchronous on Linux IIRC), then you'd probably want to introduce a new SFML event that carries the proper clipboard information.
Because calling getClipboard() until there's data "ready" feels really weird.
-
I think creating a new event is fairly un-intuitive, when all the other libraries simply have get/setClipboard functions that are synchronous.
Plus this would only be worth it on Linux, since, as Tank said, other OSes all have synchronous clipboard management.
-
Typically the clipboard is accessed when the computer user wants to copy/paste text from 1 program to another. A ~0.5 sec busy wait would be hardly noticeable.
-
I see it like you, the delay (if it's noticeable at all...) is alright, and the functions to set and get the clipboard content are much more intuitive and work as expected.
I'd like to take a look at a clipboard manager though. I wonder if they periodically poll or wait for specific events. Will read some source code later.
If changing the event pump is avoidable, I'd like to suggest such a solution.
-
I've checked some clipboard managers and SDL. The clipboard managers use GUI toolkit functions, like from GTK or Qt, so that's abstracted. SDL does poll.
So I guess the only sane solution is to add an event queue and wait for the clipboard reply. :(
-
I checked Qt, it does a blocking polling too.
-
Theoretically, getting the clipboard is quite fast, as long as the selection owner has a quick response (which is not guaranteed). This is why the current implementation on X11 has a 1-second time limit, and if that isn't met, it returns the cache.
Getting the clipboard is totally possible in a static function etc. It's setting the clipboard in a static function that's nearly impossible. Since you can't give ownership of the selection to another window, you're stuck with it and the requirement to send its contents to anybody who requests them, until someone else requests ownership. Either we could make the setClipboard function forking, like xclip does, and thus spawning an entire thread just for the sake of responding to events (until we get a SelectionClear event), or we could make it blocking and have the program wait an undetermined amount of time until the hidden window's ownership of the clipboard has been lifted.
As for performance, I don't know about you, but I easily laugh and criticize software when simple things such as clipboard usage make the whole thing lock up for even half a second. It shouldn't happen, and it doesn't have to happen, either. And if we're talking about a game, which should run at 30/60/120 FPS, having the framerate drop to 10 or 20 FPS (stutter) because the game used the clipboard is pretty bad.
I ran some tests, in microseconds (us), with 1000000 samples, on my i7 4770 (per call):
Times (min, max, avg): Get Clipboard (6, 36462, 90), Set Clipboard (15, 198679, 215).
The current method thus doesn't seem to pose a performance issue.
-
I think spawning a new thread for handling the clipboard window is the lesser evil of these two. Clipboard ownership probably won't be requested until the user tries to copy something in another program, so a blocking setter would cause the program hang until the user gives up and starts doing something else. Requiring the user to copy something in another application to make the program responsive again is bad.
With a blocking setter, the programmer would have to create a new thread anyway just for calling the setter in order to keep the app responsive.
-
I think spawning a new thread for handling the clipboard window is the lesser evil of these two. Clipboard ownership probably won't be requested until the user tries to copy something in another program, so a blocking setter would cause the program hang until the user gives up and starts doing something else. Requiring the user to copy something in another application to make the program responsive again is bad.
I only suggested it as a potential solution to show how ridiculous a potential solution would be. There is no real, simple solution to this, and the kinds of workarounds I suggested are purely to reinforce this point.
If somehow dedicating a thread to the clipboard of all things seems sane to everyone, then that's the method we'll go with, but I think that's utterly insane and a waste of resources.
-
Is there a possibility to check in a non-blocking call whether the clipboard is ready?
If so, an asynchronous (but single-threaded) algorithm would still be possible: setClipboard() just issues the order and caches the text. In regular intervals (probably in a window event loop), the clipboard is checked for availability, and set if available.
-
The problem is that SFML must also send the clipboard contents to other applications when they request it.
-
Is there a possibility to check in a non-blocking call whether the clipboard is ready?
If so, an asynchronous (but single-threaded) algorithm would still be possible: setClipboard() just issues the order and caches the text. In regular intervals (probably in a window event loop), the clipboard is checked for availability, and set if available.
That's what's being done right now. This means a non-static member function, and apparently that's wrong and makes for a horrible API. If not for this, the implementation on X11 is finished. Setting the clipboard doesn't require any event loops, it's just that to set the clipboard, you must own the clipboard, and if you own the clipboard, you need to respond to people requesting the clipboard's contents. The clipboard is thus always available, since all you're doing when you set it is taking ownership and setting your cache. No waiting involved.
Take a look at https://github.com/Mischa-Alff/SFML/blob/feature/clipboard/src/SFML/Window/Unix/WindowImplX11.cpp#L589
There's no waiting in there. All the clipboard-ownership burden stuff is in WindowImplX11::processEvent(); https://github.com/Mischa-Alff/SFML/blob/feature/clipboard/src/SFML/Window/Unix/WindowImplX11.cpp#L1352
And thus that code gets a chance to be run at regular intervals, which is what is needed.
The problem is that SFML must also send the clipboard contents to other applications when they request it.
Can you at least try to contribute to the discussion if you're going to post?
-
A member function would be OK to me. After all, if you don't have a window, then where would the user paste the clipboard contents? or whence would he copy to clipboard?
-
A window member function is not ideal for the reasons outlined in the pull request (https://github.com/SFML/SFML/pull/715#issuecomment-58212965): having a window is an platform-dependent implementation-detail resulting from X11's questionable design. As a SFML user, it does not make sense to associate the clipboard with a window (what if none or multiple ones are available?). I also find it standing to reason to have a separate sf::Clipboard class.
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?
In case a thread and a hacked window is the only possibility: there's still no need to impose that overhead on every SFML application. All that stuff could be lazily initialized upon first clipboard usage.
-
And to incorporate Tank's post on GitHub:
I think it's absolutely alright to put the event handling code in processEvent. Normal GUI applications are built around a message pump that does exactly that all the time. And since processEvent is something that gets closest to such a message pump, we should use it.
So my proposal is:
- For getting contents, run an event handler for max. 1 second and put unhandled events to a new internal queue, so that they can be processed later in processEvents.
- For setting contents, do the X11 selection request work and respond to content requests in processEvents.
- Use an internal and invisible window to handle the clipboard stuff and use static clipboard functions. To be honest, I don't like this very much, but it indeed seems like to be the best solution to workaround X11's stupid design decisions.
-
Aside from possible performance issues and simpler implementation, I know nothing that would favour the member function, but I don't believe that it would cause any problems either.
I claim that there is a window if the application needs clipboard access. Here's my rationale:
1. An application doesn't need clipboard access if the user isn't copy/pasting something.
2. The user can't copy/paste if there isn't a window to copy/paste from/to.
----------------------------------------------------------------------------------------------------------
Therefore, the application doesn't need clipboard access if there isn't a window.
Which is to say, applying transposition, that there is a window if the application needs clipboard access.
If you disagree with this, then which is the premise you disagree with?
As for the case with multiple windows, the window would be decided by the user when calling the member function, even *this
.
-
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'.
-
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 (https://wiki.libsdl.org/SDL_GetClipboardText?highlight=%28%5CbCategoryAPI%5Cb%29%7C%28SDLFunctionTemplate%29).
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.
(And to be honest: The more I think about it, X's design isn't as bad as I thought; the conversion is very flexible and the non-blocking part will allow heavy conversion operations without blocking the target application.)
-
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 (https://wiki.libsdl.org/SDL_GetClipboardText?highlight=%28%5CbCategoryAPI%5Cb%29%7C%28SDLFunctionTemplate%29).
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.)
-
Thanks for pointing out the SDL thing. Sounds like side effects. ;)
-
So, what's the opinion of you guys? Personally I think the member function is the cleanest solution.
-
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.
-
I also favour the member function.
-
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 (http://qt-project.org/doc/qt-4.8/qclipboard.html), Android (http://developer.android.com/reference/android/text/ClipboardManager.html), Java AWT (http://docs.oracle.com/javase/7/docs/api/java/awt/datatransfer/Clipboard.html), the .NET framework (http://msdn.microsoft.com/en-us/library/system.windows.clipboard(v=vs.110).aspx) are further examples that provide dedicated classes for clipboard access.
-
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 (http://qt-project.org/doc/qt-4.8/qclipboard.html), Android (http://developer.android.com/reference/android/text/ClipboardManager.html), Java AWT (http://docs.oracle.com/javase/7/docs/api/java/awt/datatransfer/Clipboard.html), the .NET framework (http://msdn.microsoft.com/en-us/library/system.windows.clipboard(v=vs.110).aspx) 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.
-
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.
-
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 ;D)
-
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.
-
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.
-
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 (http://www.gotw.ca/gotw/084.htm), 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.
-
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 (http://www.gotw.ca/gotw/084.htm), 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.
-
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?
-
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.
-
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.
-
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.
-
On Windows, it's not clear what the optional HWND argument does, and I think that most people don't use it.
-
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.
-
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 ;)).
-
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...
-
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?
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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. ;)
-
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.
-
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.
-
I haven't thought about conversions yet, but having functions in sf::Clipboard is also what I'd prefer as well.
-
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.
-
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
-
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);
}
-
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;
-
This would still feel like there's a separate clipboard for each window (as there was a separate input manager for each of them).
-
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.
-
I still prefer a sf::Clipboard interface that takes the "owner" window as an argument whenever you set new clipboard content.
-
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.
-
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 ;)
-
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.
-
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.
-
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?
-
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.
-
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?
-
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.
-
If SetClipboardData succeeds, the system owns the object identified by the hMem parameter.
-
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 :-\
-
Yeah, EmptyClipboard would fail if you called it without being the owner. Not the first time that the WinAPI is confusing. ;)
-
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).
-
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.
-
So.. no conclusion?
Now that we've been through the internals, is the current API suitable?
-
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.
-
How would the implementation look on other systems -- OS X, iOS, Android?
Does the use of XCB instead of raw X11 change anything?
-
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.
-
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);
}
-
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.
-
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.
-
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.
-
I don't think we should waste our time with an implement which doesn't have the window argument. If the implementation highly depends on it for Windows and Linux, let's keep it in our API. We can still decide to remove it later, based on the experience and feedback we get from this first implementation.
The data should always be first in the list of arguments, let's not make the window the most important one (it will also make things easier if we remove it one day).
And we should start with a neutral implementation that deals with raw data (vector<char> instead of sf::String), and implement conversions to unicode text, image, whatever on top of it.
-
And we should start with a neutral implementation that deals with raw data (vector<char> instead of sf::String), and implement conversions to unicode text, image, whatever on top of it.
Why?
We already know the type of said data, why would we store it in a vector<char> of all things? I don't think asking the user to decode everything is a good idea. A lot of people would get confused.
-
I don't think we should waste our time with an implement which doesn't have the window argument.
So, assuming the other systems don't need a window, you would still require that parameter but just ignore it in the function? On mobile systems, does the user always have a window at hand?
The data should always be first in the list of arguments, let's not make the window the most important one (it will also make things easier if we remove it one day).
I initially had it like that, but reversed it for symmetry reasons between setter and getter:
void set(Where, Value);
Result get(Where);
But you're right, both the priority of the value and the potential later removal favor the other way.
And we should start with a neutral implementation that deals with raw data (vector<char> instead of sf::String), and implement conversions to unicode text, image, whatever on top of it.
But we should definitely provide a string-based high-level function pair. Do we want to provide all MIME types from the beginning? I'd probably start with text-only clipboards and such a high level function, it's still possible to add a generic interface for further types later.
-
Why?
We already know the type of said data, why would we store it in a vector<char> of all things? I don't think asking the user to decode everything is a good idea. A lot of people would get confused.
This is not what I was suggesting. In the end we would do all the conversion job, the user will still be able to call getText, getImage, etc. directly.
What I'm suggesting is to split our implementation into two layers: the part that gets raw data + format from the OS, and another part that provides higher-level access functions, internally doing conversions from/to raw data based on the format. This would improve flexibility, not require stupid dependencies between modules (the text handler can be written in sfml-window, the image handler in sfml-graphics, etc.), and leave space for user conversions of formats that we don't support out of the box. Don't forget that sf::String is not raw data, it already performs a conversion based on a character encoding, so this must not be the "base" type for clipboard access, only one of the high-level conversion that we provide.
So:
class Clipboard
{
// these functions are directly plugged on the OS-specific implementation
static Format getFormat();
static vector<char> getData(Window& window);
static void setData(vector<char> data, Format format, Window& window);
// these functions use the above functions
static String getText(Window& window); // --> if (format() == Text) return sf::String(getData() ...);
static void setText(String string, Window& window); // --> setData(string, Text, window);
};
-
I don't think we should waste our time with an implement which doesn't have the window argument.
So, assuming the other systems don't need a window, you would still require that parameter but just ignore it in the function? On mobile systems, does the user always have a window at hand?
Very few people write console applications with SFML.
Nobody writes windowless applications with SFML on Android.
And we should start with a neutral implementation that deals with raw data (vector<char> instead of sf::String), and implement conversions to unicode text, image, whatever on top of it.
But we should definitely provide a string-based high-level function pair. Do we want to provide all MIME types from the beginning? I'd probably start with text-only clipboards and such a high level function, it's still possible to add a generic interface for further types later.
As I've said: supporting "as many MIME types as possible" isn't an issue. Other (similar) libraries only support a text clipboard (UTF-8), and nobody is complaining.
While planning ahead for potential additional MIME types is a good idea. We'll probably never get any, and if we do, it'll be in a somewhat distant future.
This is not what I was suggesting. In the end we would do all the conversion job, the user will still be able to call getText, getImage, etc. directly.
What I'm suggesting is to split our implementation into two layers: the part that gets raw data + format from the OS, and another part that provides higher-level access functions, internally doing conversions from/to raw data based on the format. This would improve flexibility, not require stupid dependencies between modules (the text handler can be written in sfml-window, the image handler in sfml-graphics, etc.), and leave space for user conversions of formats that we don't support out of the box. Don't forget that sf::String is not raw data, it already performs a conversion based on a character encoding, so this must not be the "base" type for clipboard access, only one of the high-level conversion that we provide.
So:
class Clipboard
{
// these functions are directly plugged on the OS-specific implementation
static Format getFormat();
static vector<char> getData(Window& window);
static void setData(vector<char> data, Format format, Window& window);
// these functions use the above functions
static String getText(Window& window); // --> if (format() == Text) return sf::String(getData() ...);
static void setText(String string, Window& window); // --> setData(string, Text, window);
};
Is this not overcomplicating something that should just be two simple functions?
What does getData return if we request formatted text? An image? A sound clip?
Plus, we can't get the "format" of the clipboard. We can only ask if conversion to a specific format is possible.
EDIT: We can ask for a list of available formats on Linux, not sure about Windows. The point is: there isn't a single available format, even just for text there are a bunch.
-
EDIT: We can ask for a list of available formats on Linux, not sure about Windows.
That should definitely be investigated. If we know the format, it allows for a simpler and more flexible implementation.
Seems like it is possible on Windows (http://msdn.microsoft.com/en-us/library/windows/desktop/ms649038(v=vs.85).aspx) too.
And I think we can safely assume that it is generally available, since Qt more or less provides the same feature (QClipboard::mimeData(), then QMimeData::hasxxx() functions).
-
EDIT: We can ask for a list of available formats on Linux, not sure about Windows.
That should definitely be investigated. If we know the format, it allows for a simpler and more flexible implementation.
Seems like it is possible on Windows (http://msdn.microsoft.com/en-us/library/windows/desktop/ms649038(v=vs.85).aspx) too.
Then yes, it's possible.
Unrelated to what you just compared to Qt, but we really should stop comparing to Qt. It's a huge, high-level library that serves a completely different purpose. They don't care if the API is bloated, or if the code is slow, and they probably didn't have a single person implementing it.
-
Unrelated to what you just compared to Qt, but we really should stop comparing to Qt. It's a huge, high-level library that serves a completely different purpose. They don't care if the API is bloated, or if the code is slow, and they probably didn't have a single person implementing it.
I didn't compare the API, it was just to prove that this feature can be implemented across all platforms that we support, without wasting time browsing each OS documentation.
-
Maybe we should focus on the functionality instead of the API right now.
With this kerfuffle, only two people other than me have tested my PR and given me results.
Can people test, give me results, etc?
For the sake of not having this lost in "PRs we couldn't agree on", perhaps this should get merged, and an issue should be created on GitHub for fixing the API?
The arguments could be listed there, and anybody who wants to fix the API and/or contribute to the discussion can do so.
-
"fixing the API" = breaking the API => Can only be done for every major version.
If everything was just merged without thinking about the API, SFML wouldn't be where it is today. So it won't be merged for the sake of having it merged, but it will be merged once it's done, meaning the API has been decided, it has been tested enough and has been reviewed. ;)
-
"fixing the API" = breaking the API => Can only be done for every major version.
If everything was just merged without thinking about the API, SFML wouldn't be where it is today. So it won't be merged for the sake of having it merged, but it will be merged once it's done, meaning the API has been decided, it has been tested enough and has been reviewed. ;)
I understand.
-
And don't worry, it won't get lost just because it is not merged ;)
-
Okay.
To whoever wanted to be able to get raw clipboard data:
Here is the list of target formats on Linux: http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2
Take a very good look at it and tell me if you see "RAW" anywhere, because I don't. Perhaps I'm wrong, and that's great!
To whoever wants to support 26 different selection formats:
Here is the list of target formats on Linux: http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2
Take a very good look at it and tell me if you see more than 3 that are interesting to you. I can find three interesting formats:
- Text/String/UTF-8
- Images
- Timestamps?
Of all of those, timestamps are the most necessary! (That was irony, by the way)
To those who have an irrational fear of API clutter:
This means that we'd get at most two get/set clipboard functions in the sf::Window class for text and.. timestamps, and one in the sf::RenderWindow class for images. That's not API clutter.
As zsbzsb and I said:
Realistically, we'd have one function in sf::Window for text, and an overload, for images, in sf::RenderWindow.
To those who want to compare to Qt:
Stop. Qt is a huge, high-level library. If I remember correctly, some people enjoy calling SFML a low-level library. So why are you comparing both?
To those who want to compare to SDL:
This isn't C, this is C++. We have OOP and all these wonderful things. Also SDL is much bigger than SFML and nobody cares if it has "bad" hacks.
To those who think a clipboard class is a better idea:
On Windows and Linux, you're getting the clipboard from the window. No point in hiding that from the user. You must also assume the user isn't a complete moron. Seriously. I don't mind making things "user friendly", but the user has to know what a clipboard is, and how to use it. It's not the window's clipboard, but you are giving the clipboard contents to the window, and you are getting the clipboard contents from the window.
To those who want a getAvailableFormats function:
I actually agree. This is a good idea, and it can be implemented whenever someone decides to add an sf::Image overload.
Regarding the allWindows vector:
It's a horrible, horrible hack. I don't care who wrote it. There's a much better way of doing this (almost identical procedure to how it's done on Windows), and a little Googling and reading some documentation and headers would prove very useful.
That's pretty much all I can think of.
And don't worry, it won't get lost just because it is not merged ;)
Yes it will.
-
Consistently being an asshole isn't going to get anybody to agree with you. The dev team takes API changes and additions into great consideration before allowing it to become merged. It's great that you're contributing and doing a lot of research for the community and SFML itself, but you don't need to be so pushy. Your contributions won't go unnoticed, but they won't be pushed in hastily either.
I do agree with you it'd be nice for a decision to be made soon (so that we can actually use this addition officially), but there's nothing wrong with considering the long-term usage and expandability of a potential addition to a maturing project. Perhaps there should be a poll similar to the one about SFML context handling which lays out the pros and cons of each option?
-
Nobody wanted raw clipboard data nor 26 formats. I just said that it should be investigated, and considered if possible. Since you're the one who has knowledge about the implementation, you're obviously the only one who can answer these questions. So calm down, you're not fighting against anyone. And it's a little disappointing that with the new team and organization, you still think that such a contribution, that caught everybody's attention, can be lost and ignored.
Anyway, thanks for answering these questions. I'll try to think about it and see where we can go.
-
So what is the status of this feature and discussion?
The PR (https://github.com/SFML/SFML/pull/715) certainly needs rebasing and most likely adjusting.
Let's take a look at it with fresh eyes and keep the discussion objective and less hostile. ;)
-
I'll try to sum up the current status:
- The PR needs more testing, for technical validation
- We all agree that getting and setting clipboard data must be tied to a sf::Window
- We all agree that only text data is relevant -- let's keep image data for later
About the API, I'm still in favor of
sf::Clipboard::setData(string, window);
string = sf::Clipboard::getData(window);
Instead of
window.setClipboardData(string);
string = window.getClipboardData();
Technically it's completely equivalent, but I prefer this design because:
1. it emphasizes the clipboard, then the data; the window, while still being mandatory, is just an argument
2. it doesn't give the false impression that each window has different clipboard data; instead it focuses on the global nature of this data
3. instead of adding more and more functions to the sf::Window class, this new functionality is kept separated in its own class, which makes maintenance and evolution easier
I can live with the other implementation though, if more people prefer it, or if technical limitations make it the only possible design.
-
Personally, I think it would make more sense if "window" was the first argument in both setData and getData. Otherwise, that all sounds right to me.
-
sf::Clipboard::setData(string, window);
string = sf::Clipboard::getData(window);
...
2. it doesn't give the false impression that each window has different clipboard data; instead it focuses on the global nature of this data
Huh? If you have to use the window at all, to me, it makes it sounds like the clipboard data is set per window.
-
We all agree that getting and setting clipboard data must be tied to a sf::Window
Not quite all. :P
Is it because of a limitation/design choice of the Linux/Windows API? Because on OS X clipboard (a.k.a pasteboard) are not tight to a window but the application directly.
I guess I'll find a way around that if we decide to stick to your proposition (like a comment in the doc explaining that the window doesn't matter on OS X).
In any case, the sf::Clipboard version sounds better. But I disagree with Ixrec: for consistency with sf::Mouse:: setPosition(), the window parameter should be the second one.
Also, what do you think of setString/getString instead of setData/getData? It would be easier later to add set/getData for images (png, jpeg, pdf, ...) or any other kind of data. And it would be close to sf::Text API too (if relevant).
-
Huh? If you have to use the window at all, to me, it makes it sounds like the clipboard data is set per window.
It is less less less less obvious in
std::string sf::Clipboard::getString(sf::Window& owner);
... where the window is just an argument which can be named so that any confusion is avoided, than in
std::string sf::Window::getClipboardString();
... where the window is the instance on which you call the function
Also, what do you think of setString/getString instead of setData/getData?
I don't know. Since we don't know the encoding (?) we should make it look like it's raw data rather than an encoded string.
-
Sorry I'm still lost. Is clipboard data stored per window? I mean, if I set the clipboard data in my application, can I then paste it into notepad or whatever? If the data isnt stored per window, why does the window need to be passed?
-
Sorry I'm still lost. Is clipboard data stored per window? I mean, if I set the clipboard data in my application, can I then paste it into notepad or whatever? If the data isnt stored per window, why does the window need to be passed?
The earlier pages of the thread cover this in exhaustive detail, but if I remember everything correctly, basically the X11 and Windows clipboard APIs require that a particular window is involved when interacting with the clipboard (Mac OS doesn't require one, but obviously we want a cross-platform interface). I forget if it served any particular purpose on Windows, but in X11 the clipboard is apparently something that gets passed around between windows, and once you acquire it you have to start listening for other applications' clipboard requests so you can pass it on to them as needed (yes, it's very strange). As far as I can recall, there is no such thing as per-window clipboard data on any of these systems.
At least in my opinion, getClipboard(window) is a sensible way to make the API reflect the unfortunate truth that you need a window to talk to the clipboard even though the clipboard is a global object. That and it's nice to have clipboard methods not be part of the Window class.
-
Thanks that makes sense. In that case, I'll +1 having the clipboard stuff be its own interface.
-
It seems that the API people want is sf::Clipboard::set(string, window). How should this be implemented in a way that the X11 window can properly respond to selection related events?
-
This window things makes me a bit uneasy: when I look at Qt doc (http://doc.qt.io/qt-5/qclipboard.html#details) or Wx doc (http://docs.wxwidgets.org/trunk/classwx_clipboard.html), none use a window in the API, and so does SDL. So if SFML choose to be different, that's perfectly fine with me, but we better have strong arguments. The only one I could find -- sorry if I missed some -- in the previous pages was only to simplify the implementation, which is not a great argument IMO.
I had a look at OpenClipboard on msdn (http://msdn.microsoft.com/en-us/library/ms649048%28VS.85%29.aspx) and apparently the window parameter is optional (*).
It seems that only X11 requires a window. Is it different with XCB? (It's getting late and I have exams to prepare so I let the linux expert among you deliberate on that. :P)
Also, what do you think of setString/getString instead of setData/getData?
I don't know. Since we don't know the encoding (?) we should make it look like it's raw data rather than an encoded string.
I haven't made my mind on that, but requiring an ANSI string from the user for the first version should be alright. Later, we can add MIME or UTI (http://en.wikipedia.org/wiki/Uniform_Type_Identifier) later and use them to choose the encoding, I guess.
(*) be aware that EmptyClipboard should not be called in that case.
-
Don't forget Android and iOS -- they seem to not require a window handle, either.
So far, it's really
"we have to reflect the underlying implementation details in the API"
vs.
"we have to make the API as easy as possible to use, taking into account a more complicated implementation"...
-
Hiura, X11 is the protocol, Xlib and XCB the libraries that talk X11. So yes, same with XCB.
-
Regarding the API: In case you want to drop the window parameter, you will have to maintain a global window array. And you also have to make sure that the selection is owned by an existing window.
I don't like global arrays and the fact that sf::Window itself would be dependent on it.
I don't see issues with providing and optionally ignoring the parameter. We just can't make a good API that pleases all platforms, the differences are too elementary.
I vote for keeping the internals clean by avoiding another global state object (such things had already blown up programs in the past) and exposing the window implementation detail to the API.
-
Yes, this has already been discussed in details in the previous pages, we should now try to move forward ;)
Regarding the implementation: can this somehow be handled entirely on the sf::Clipboard(Impl) side, like for example with a thread, Window::getSystemHandle() and a separate event loop, or would sf::Clipboard have to be a front-end to private functions of sf::Window?
-
Thanks Tank for the explanation. (When it comes down to X11 I'm a complete noob. ;))
@Laurent, agreed. We can still refined our judgment in 3.0 anyway.
-
So can we ever agree to an implementation?
-
Setters and getters probably have to forward the job to some private sf::Window functions, and the clipboard requests could be handled among other events in processEvent.
Are there more implementation details to decide about?
-
If we can't get this feature moving anytime soon, it most likely won't make it into SFML 2.3. ;)
-
Before this descends into a gaping abyss, let's come up with the final API 8)
The main controversy in this thread revolved around the appearance of a window in the API (which is needed by some, but not all platforms). Towards the end of the discussion, many arguments were in favor of an independent sf::Clipboard class with static functions taking a window parameter:
class Clipboard
{
public:
static void copy(sf::Window& window, const sf::String& text);
static sf::String paste(sf::Window& window);
};
However, this is not ideal from an object-oriented and semantic perspective; it's neither intuitive nor handy to have a window around whenever the clipboard is used.
I have a new idea that would combine both requests (have a window in the API but without clutter). We essentially move away from the global access -- but keep in mind that was illusory, because you had to keep a window around. This API uses an instance-based (non-static method) approach:
class Clipboard
{
public:
void copy(const sf::String& text);
sf::String paste() const;
private:
sf::Window* m_window;
};
class Window
{
public:
Clipboard getClipboard(); // const?
};
This has several advantages over both a purely sf::Window-based interface and a singleton-style sf::Clipboard class:
- The interface is much simpler. The user need not specify the window all the time.
- We don't have a global class, thus resource lifetimes can be bound to the object, not the program duration (either sf::Clipboard, but probably more meaningful sf::Window).
- We can use const-correctness: if we want certain modules to only read but not write to the clipboard, we pass them a const-reference.
- A window is not strictly required: a platform can provide other means of creating sf::Clipboard instances.
What we can still discuss is whether sf::Clipboard has value semantics, and every instance refers to the same clipboard; or whether we make it noncopyable and allow only to pass around pointers and references.
What do you think of this idea? :)
-
I like this approach, it really seems to combine all the ideas into one solution. The only thing I'd change is the function names: "copy" to "set" and "paste" to "get", because you set/get a clipboard, you don't copy/paste it. But other than that, nice.
-
I don't think that your modification makes much difference:
window.setClipboardData(...);
// vs
window.getClipboard().setData(...);
So my comments about the solution that I presented still apply:
2. it doesn't give the false impression that each window has different clipboard data; instead it focuses on the global nature of this data
3. instead of adding more and more functions to the sf::Window class, this new functionality is kept separated in its own class, which makes maintenance and evolution easier
-
As mentioned in earlier posts, I'm also fine with a solution that hides the window entirely. And now that you mention it again, it makes sense to have a truly global access point.
The question is then which window the implementation would choose, or if it would always create a hidden one.
About naming: Why not copy/paste? That's exactly what a clipboard does. Like this, it's obvious how the functions correspond to user commands like Ctrl+C, Ctrl+V.
-
A clipboard is the place where copied data gets stored, and where you paste data from. The clipboard itself doesn't do that.
-
Copy/paste is end-user semantics for the application where there also exists cut, which does (for the end-user) something very different to copy but as far as the clipboard is concerned, not very different (unless you actually move the content, in which case you would need to provide another method, move, to transfer pointers or whatever).
-
A clipboard is the place where copied data gets stored, and where you paste data from.
Yes, that would only add a preposition, which I omitted for simplicity:
Clipboard::copyTo()
Clipboard::pasteFrom()
Copy/paste is end-user semantics for the application where there also exists cut, which does (for the end-user) something very different to copy but as far as the clipboard is concerned, not very different (unless you actually move the content, in which case you would need to provide another method, move, to transfer pointers or whatever).
You might be right, "copy/cut/paste" are perhaps higher-level terms used in the UI rather than the OS interface.
I personally thought "copy sth. to the clipboard / paste sth. from it" is easier and more intuitive to understand than "set a value in the clipboard / get a value from it".
Further opinions? Also not only regarding the naming?
-
I'd prefer a solution that doesn't incur unnecessary overhead (eg. a superfluous hidden window). Other than that, I'm ok with any interface or implementation. I'm just looking forward to getting clipboard support to SFML.
-
I still have to reply for the naming. ;)
Clipboard::copyTo()
Clipboard::pasteFrom()
Compare this to:
Object::copyTo()
Object::pasteFrom()
In the 2nd case, you would clearly say that the object is copied to somewhere or pasted from somewhere. This is actually the same with Clipboard::*. I guess the sole reason why it's confusing is that it's, like said, not the clipboard that's performing the copy/paste/cut operations, but the user. The clipboard is utilized to fulfill the operations, by setting and getting its contents.
-
I thought about it again after further input. So far, the main argument to use a window in the API is to reflect the underlying OS-specific APIs. Since SFML is an abstraction, those are implementation details, and there exists no reason per se to propagate them to the public API. Easy of implementation is not a good argument, especially not when it comes at the cost of ease of use.
On the other side, there are good arguments to have a hidden window:
- The clipboard feels global in nature, linking it to a window makes no sense from user perspective
- Associated with a window, the semantics are confusing: what happens when we set the string at one window and get it from another?
- The user need not carry around a window object when accessing the clipboard, usage thus gets simpler
- On some platforms (e.g. Android) there's not even a window behind the scenes, so the implementation would just ignore it anyway
So, I'll suggest we proceed with a hidden window and a truly global sf::Clipboard class. Regarding the naming, I'm okay with "setString/getString".
-
Good to see someone finally sharing my point of view.
However this would mean global variables / hidden windows / or whatever that we don't want to see again in our internal code.
But until someone tries to implement a global clipboard, we'll never really know. The thing is, we need at least the 3 desktop implementations to be sure :-\
-
Before I forget, here is a SO answer describing the pretty straightforward implementation to get the content of the clipboard for OS X and iOS: http://stackoverflow.com/a/6167746/520217
-
@Nexus
Don't you use sf::Window on Android, as well?
-
@Nexus I think the main argument against a hidden window (& thread on x11) is that it makes everybody pay for a feature almost nobody really needs.
But never mind, I think it is possible to have a hidden window AND let user provide his own.
Here's a semi-pseudocode sketch of what I'm thinking:
struct ClipboardManager
{ explicit ClipboardManager(bool useDefaultBroker=true)
{ if true // false-> a broker window must be manually set before use
{ if usersOfHidden==0 startHidden();
++usersOfHidden;
usingHidden=true;
} else usingHidden=false;
}
explicit ClipboardManager( Window& broker);
void setBroker( Window& );//<^User provided window
void setDefaultBroker();// Does same as default constructor
string getStr();
void setStr(string);
static bool needsWindow();// Would be nice to know (for user-provided window users)
~ClipboardManager(){ if usingHidden && --usersOfHidden==0 quitHidden();}
};
I don't think a global window is necessary. The ClipboardManager objects should create hidden stuff on demand and destroy it when it isn't used anymore.
-
I think the main argument against a hidden window (& thread on x11) is that it makes everybody pay for a feature almost nobody really needs.
Pay what? The main argument against this is mainly about internal code, it doesn't change anything for end users.
But never mind, I think it is possible to have a hidden window AND let user provide his own.
The reason for hiding the window is to make the API simpler and cleaner. I'd prefer an extra window argument to all the clutter that you add to the Clipboard class :P
-
I think he's referring to C++'s "don't pay for what you don't use" concept. A hidden thread and/or window are contrary to that train of thought. If someone doesn't need/want clipboard support, they're automatically getting extra stuff in their SFML application.
Would a setClipboardEnabled or something function be plausible? Kind of like setKeyRepeatEnabled and setVerticalSyncEnabled. That would satisfy what Juhani mentioned, I think.
But then again, for me, I'm not really sure what I'd like (as a user) for this API. I see the merits of a global sf::Clipboard class, but then again, if it's possible to not have more stuff going on in the backend, that'd be nice.
Maybe an optional Window argument? If a (valid) Window object is given as an argument, use it, otherwise, use a global Window.
-
I think he's referring to C++'s "don't pay for what you don't use" concept. A hidden thread and/or window are contrary to that train of thought. If someone doesn't need/want clipboard support, they're automatically getting extra stuff in their SFML application.
Why? You could create that on first use. Problem solved :)
But then again, for me, I'm not really sure what I'd like (as a user) for this API. [...] if it's possible to not have more stuff going on in the backend, that'd be nice.
Maybe an optional Window argument? If a (valid) Window object is given as an argument, use it, otherwise, use a global Window.
It doesn't make sense to argue from a user/API perspective and talk about stuff happening in the background.
How would providing two APIs for the same help, just so that users with a bad feeling in the stomach are happy too? ;)
-
Why? You could create that on first use. Problem solved :)
Well yeah, I guess that would work. This would be why multiple brains on a problem are good, haha. :)
It doesn't make sense to argue from a user/API perspective and talk about stuff happening in the background.
Well, the user-facing API is dependent on the background, correct? So would it not then be relevant?
Besides that, I like knowing what's going in the background. Regardless of the chosen API/background/etc, I'll be happy with having it, I'm just curious and want to know about the different options, that's all.
How would providing two APIs for the same help, just so that users with a bad feeling in the stomach are happy too? ;)
I don't see how an overload/whatever is two different APIs. I meant function overloads (or another method of doing this). Just something like:
someClipboardFunction(someArg)
{
someClipboardFunction(someArg, globalClipboardWindow);
}
someClipboardFunction(someArg, window)
{
stuff
}
Maybe I'm misunderstanding what you meant, though.
-
Well, the user-facing API is dependent on the background, correct? So would it not then be relevant?
The whole point of an API (application programming interface) is to abstract from what happens in the background -- i.e. to provide an interface for a user. In SFML, we try to provide the simplest possible APIs (see philosophy (http://www.sfml-dev.org/contribute.php#philosophy)). When designing APIs, the focus lies on making it user-friendly, not developer-friendly, and the intent is not that the internal implementation details are mirrored to the outside.
Besides that, I like knowing what's going in the background.
Yes, but you can still know that when looking deeper into the documentation or the code. It's an open-source project, no knowledge is hidden. That in turn doesn't imply those things should be represented in the function signatures :)
I don't see how an overload/whatever is two different APIs.
When we provide two different ways to achieve the same thing, we have two interfaces for one piece of functionality. I'd like to avoid that where possible, because it causes confusion, as users start to wonder why there were two ways in the first place.
Keep in mind that the vast majority will not remotely know about the discussion we're just having here. They won't even care in fact. All they want is simple access to the clipboard -- and any additional part we're adding for obscure reasons is an obstacle to them.
-
The reason for hiding the window is to make the API simpler and cleaner. I'd prefer an extra window argument to all the clutter that you add to the Clipboard class :P
I don't know what you mean by clutter :P
Why? You could create that on first use. Problem solved :)
Creating and destroying the hidden stuff in accordance to the need helps a lot, but the hidden stuff still is just what virtually all user applications would have anyway, and therefore redundant. But the only way to get rid of that redundance is to allow the user point a window to use.
-
Does the clipboard window need to be a dedicated one with just this usage?
Earlier in the discussion, a global list of user windows (as it already exists on Linux) was mentioned... The clipboard might also make use of that.
-
Earlier in the discussion, a global list of user windows (as it already exists on Linux) was mentioned... The clipboard might also make use of that.
Would the window be picked arbitrarily?
What if it gets destroyed suddenly?
Would you still have a dedicated thread (or would you just hope that the window's events are handled regularly)?
Would the thread interfere with the normal use of the window? (Can it be avoided?)
-
Those are "just" some implementation details. A good API should not suffer from that kind of issue.
But as Laurent said:
But until someone tries to implement a global clipboard, we'll never really know. The thing is, we need at least the 3 desktop implementations to be sure
So we already got one for OS X (well, kind of, I can do it very easily). I forgot about Linux's status: do we have one or could somebody do it? And then there's Windows.
So what about we try and see? I mean, we have been on this topic nearly a year and I feel we're just circling around. ;)
-
Yes, totally. I'll try to come up with an implementation for Windows as soon as I have some time.
Would be nice if somebody a bit more experienced with X11 could try something on Linux. If nobody ever gets to it, I could also make an attempt, but I first have to install Linux again ;)
-
Don't forget that this topic was started with an implementation for Windows and Linux (if I remember correctly). Don't restart from scratch ;)
-
Thanks! In fact I already had a brief look at Aster's code :)
Other libraries may of course also serve as inspiration.
-
Don't forget that Aster also said that he is willing to carry on his PR if you guys can manage to agree on something. So don't be jumping the gun and maybe give him a chance to update the PR.
I can rewrite it and/or fix any issues with it if someone comes up with a viable API.
-
Jumping the gun? Nobody wrote any code for 3/4 of a year... The API we're talking about has been suggested last autumn already, and Aster strongly disliked it (http://en.sfml-dev.org/forums/index.php?topic=16462.msg119296#msg119296), which is why I thought he wouldn't be willing to implement it.
Working further on the same PR would of course not mean throwing away Aster's code, his commits and contributions could still remain as a foundation. I'm also okay with him continuing, but I don't want to let a few more months pass before anything happens. Now I have at least a bit of time to work on such things ;)
Actually: since he seems to have investigated the X11 semantics to a great detail, it would make sense if he continued the Linux implementation :) he hasn't been in the forum for a while, can anybody contact him?
-
I'm eager to see how ye are going to implement this with no hidden window && no hidden thread. ::)
-
he hasn't been in the forum for a while, can anybody contact him?
I notified him on an IRC channel that he should read the new updates on this thread, so... :-\
-
I'm eager to see how ye are going to implement this with no hidden window && no hidden thread. ::)
That's not possible. If the user has no window, we have to create (a hidden) one of course.
This whole "reuse user's windows" story is only an optimization. It needn't be part of the first version... We should rather focus on getting the basic functionality running.