SFML community forums

General => SFML development => Topic started by: eXpl0it3r on March 21, 2017, 03:58:13 pm

Title: Clipboard Support
Post by: eXpl0it3r on March 21, 2017, 03:58:13 pm
Info & Rules (http://en.sfml-dev.org/forums/index.php?topic=21541.0) about this sub-forum

Note: Just to prevent potential confusion, this subforum is not just dedicated to SFML 3 discussions, but it's open to any SFML development topics like the this one right here.

Clipboard support has been a long requested feature (thread #1 (http://en.sfml-dev.org/forums/index.php?topic=1112.0), thread #2 (http://en.sfml-dev.org/forums/index.php?topic=12251.0)) for many obvious reasons. In the past we had one attempt (forum post (http://en.sfml-dev.org/forums/index.php?topic=16462.0), pull request (https://github.com/SFML/SFML/pull/715)) at getting it implemented, but the discussion dragged on for a while and after the API discussion was mostly finished, nobody took it up and actually implemented the suggestion, until now...

In the past few weeks Ricardo (aka Ricky) has been working on a new implementation: https://github.com/SFML/SFML/pull/1204
His implementation seems to mostly resemble what had been discussed and is up to date with SFML's code base (switch back to Xlib).
While this thread can be considered a continuation of Aster's thread (http://en.sfml-dev.org/forums/index.php?topic=16462.0), I think starting fresh makes more time. I will try to summarize previous discussions.

I also like to mainly focus on the implementation bits and less about how the functions should be named, as this is a minor detail and will easily distract from the important discussion points.

Proposed API
// Get the content of the clipboard as string data
sf::String str = sf::Clipboard::getString();
// Set the content of the clipboard as string data
sf::Clipboard::setString(const sf::String& str);
 

Requirements

Previous Decisions

Current implementation

Questions

Example code
(click to show/hide)
Title: Re: Clipboard Support
Post by: Ricky on March 21, 2017, 08:06:37 pm
Thanks for bringing attention to my PR eXpl0it3r. There is a typo in your pasted demo code.
The second test string should say "Hello world, Καλημέρα κόσμε"

I'd love to see what people think about how it is implemented and how it can be made better.
Title: Re: Clipboard Support
Post by: eXpl0it3r on March 22, 2017, 01:08:24 am
Thanks for bringing attention to my PR eXpl0it3r. There is a typo in your pasted demo code.
The second test string should say "Hello world, Καλημέρα κόσμε"
Hmm, this is auto converted when using the [code=cpp][/code] apparently. Made a quote out of it. No highlighting, but also no weird character conversion. :D
Title: Re: Clipboard Support
Post by: Tank on March 22, 2017, 10:33:59 pm
I didn't review the PR yet, so I can't comment on the implementation. But that's not the goal of this thread anyway.

Are there drawbacks of creating a hidden window? If there are none, I'd say it's good enough.
Title: Re: Clipboard Support
Post by: eXpl0it3r on March 30, 2017, 11:41:34 am
Well, I was hoping for a bit more activity, guess I'll give it a go then.

Is the Linux implementation acceptable for us?
From what I've read in the previous discussion, the current implementation is pretty much the only way. We need a window and we need to hook into the window's event processing. One thing I'm not certain about is, whether the busy-waiting loop with sleep-calls is required. Can this be better solved with waiting for events?

For Linux, should we instead try to use the global vector of windows that already exist in the window class? And how do we get access to the event processing of the given window?
While this would allow us to reuse an existing window, I feel like it would require more work and I'm not sure if it's even possible.
To get access to the global vector, we'd somehow have to get access to the window class, which can be done by using friend, but then not every implementation needs that access.
Since the window in that list probably process their own events already, how do we get in the middle of that to check for the clipboard events? If there's a method, how can we ensure that our intervention doesn't a bad side-effect on the normal event processing?

For Windows, there's currently no window handle used, should the implementation be adapted to use a window handle? And how should the clipboard class get access to an active window handle?
I would like an implementation that uses a proper window handle, since a) this is what the MSDN requires and b) because other libraries do so as well. However, since using NULL seems to work as well, I'd be fine keeping the current implementation for now. If we ever run into weird behavior and/or figure out under want circumstances NULL doesn't cut it anymore, we can always try to find a different implementation, after all, the implementation shouldn't change the public API.

For Linux and Windows, what should happen if there's no active window available?
Since I'm fine with the current Linux implementation, such a scenario doesn't exist.
If we ever do decide to change the Windows implementation, I wonder if a hidden window/window handle is a thing on Windows?

I didn't review the PR yet, so I can't comment on the implementation. But that's not the goal of this thread anyway.
Well it's part of the goal of this thread. We have a (probably?) fixed API and now have a possible implementation. So on one hand we're still discussing some general concepts, on the other hand, we have a working implementation that we can discuss

Are there drawbacks of creating a hidden window? If there are none, I'd say it's good enough.
We're already creating hidden windows on Linux and it hasn't had a negative effect so far. Not sure however if a window that is isolated like the one in sf::Clipboard could have any drawbacks.
Title: Re: Clipboard Support
Post by: Tank on April 03, 2017, 09:04:01 am
Quote
Well it's part of the goal of this thread. We have a (probably?) fixed API and now have a possible implementation. So on one hand we're still discussing some general concepts, on the other hand, we have a working implementation that we can discuss

Just took a look at the implementation. It's totally fine for me, except some minor things. The API is super simple and seems to work just fine, so merging and testing is what I'd say now.
Title: Re: Clipboard Support
Post by: Ricky on April 06, 2017, 05:58:28 am
Just updated some stuff on Github. Comments please!
Title: Re: Clipboard Support
Post by: Ricky on April 06, 2017, 05:19:42 pm
Just to be clear we are all on the same page that sf::Clipboard does not need an example and that it should be detailed in the documentation?
Title: Re: Clipboard Support
Post by: Tank on April 06, 2017, 07:43:52 pm
An example isn't bad per se, but creating one just to show `sf::Clipboard` is definitely overkill. So yeah, documenting it should be alright (it's not hard to use/understand anyway).
Title: Re: Clipboard Support
Post by: dabbertorres on April 07, 2017, 09:23:45 am
For what it's worth, I don't think an example could hurt at all! At least, I've never seen "too much documentation"; professional or open-source. ;D
Title: Re: Clipboard Support
Post by: Laurent on April 07, 2017, 09:40:32 am
A lot of things "wouldn't hurt", this doesn't prevent us from trying to be relevant. And I don't think a full example for demonstrating how to use "setString / getString" is relevant beyond the documentation.
Title: Re: Clipboard Support
Post by: sjaustirni on April 07, 2017, 05:53:52 pm
A lot of things "wouldn't hurt", this doesn't prevent us from trying to be relevant. And I don't think a full example for demonstrating how to use "setString / getString" is relevant beyond the documentation.
+1

A minimal, compilable example of the implemented feature in a PR thread is really beneficial for testing, so people with different systems can easily check for the correctness of the implementation. Once tested though, for what is essentially a two function API, a simple mention in the docs is all that's needed.
Title: Re: Clipboard Support
Post by: Ricky on April 09, 2017, 04:23:24 am
Okay so I fixed up the documentation and removed the copy paste errors and the example. Comments?
Title: Re: Clipboard Support
Post by: Ricky on April 17, 2017, 04:53:10 am
Thanks guys for all the support with this PR. Honestly my first time using Github to contribute to someone else's code so forgive me if I'm doing things backwards, hopefully next time things will go more smoothly.

Tank: Could you check your review? I think I may have applied the necessary changes and if so I'd appreciate it you'd approve it.

Let's see where we go from here  :)
Title: Re: Clipboard Support
Post by: Phanoo on September 02, 2017, 04:29:25 pm
When this will be available ? I'm making a program, and this feature is lacking since Years, it would be very nice to have it
Title: Re: Clipboard Support
Post by: eXpl0it3r on September 02, 2017, 04:31:49 pm
It has been merged into master a few weeks ago. ;)
Title: Re: Clipboard Support
Post by: Hapax on September 02, 2017, 04:51:05 pm
I couldn't find any discussion about this directly so I had a look at the code:
sf::Clipboard allows transfer of text strings only.

It's understandable but I found it odd that I couldn't find any discussion on why that is.

What happens when the system clipboard contains something else? Does it discard it or treat it as some form of string?

Is there a reason it can't use raw memory blocks, for example?
Title: Re: Clipboard Support
Post by: eXpl0it3r on September 02, 2017, 05:15:02 pm
There has been discussions around this somewhere, you may want to check the linked threads in the first post.

Afaik the clipboard doesn't work with "raw memory blocks".
The goal was to just provide a first implementation for text and delay the handling of different mime types to a later point.
IIRC if you copy none-text data, you simply can't "insert" it in SFML.
Title: Re: Clipboard Support
Post by: Hapax on September 03, 2017, 02:13:58 pm
I did look around the multiple pull-requests too and couldn't easily see it being discussed. It was probably either discussed alongside other issues (hiding) or maybe discussed in IRC?

Of course, this doesn't matter and I did say that it was understandable that it was string only. As you say, it's only the first step ;D

IIRC if you copy none-text data, you simply can't "insert" it in SFML.
I was hoping that this was the case. I don't know much about how system clipboards work so don't know if they have any information about its format; I'm guessing they do somewhat.