Clipboard Support

[eXpl0it3r]

Info & Rules 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, thread #2) for many obvious reasons. In the past we had one attempt (forum post, pull request) 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, 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

• Linux (X11) requires access to a window's event processing and thus requires the use of a window.
• Windows claims in MSDN to require a window handle to set the clipboard content, but in practice it seems to also work with a handle of NULL. For comparison, SDL and GLFW provide a window handle.
  
• OS X and iOS don't require a window at all.
  
• Android doesn't seem to require a window either.

Previous Decisions

• The clipboard should not be part of the sf::Window API, but it's own class.
  
• The use of a window is an implementation detail and should not be reflected in the public API.

Current implementation

• For Linux, the implementation uses a dedicated, hidden and lazy-loaded window with its own busy-waiting thread to handle the events.
• For Windows, there's no window handle used, instead NULL is passed to OpenClipboard.

Questions

• Is the Linux implementation acceptable for us?
• 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?
• 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?
• For Linux and Windows, what should happen if there's no active window available?

Example code

(click to show/hide)

#include <iostream>
#include <SFML/Graphics.hpp>
#include <SFML/Window/Clipboard.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(420, 380), "SFML Clipboard");

    sf::Font font;

    // Replace with your font file
    if(!font.loadFromFile("./YourFont.ttf"))
    {
        std::cerr << "Failed to load font file." << std::endl;
        return -1;
    }

    sf::Text text("Clipboard!", font);

    while(window.isOpen())
    {
        sf::Event event;
        while(window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
                window.close();
            if(event.type == sf::Event::KeyPressed)
            {
                if(event.key.control && event.key.code == sf::Keyboard::V)
                    text.setString(sf::Clipboard::getString());
            }
        }

        if(sf::Keyboard::isKeyPressed(sf::Keyboard::Num1))
            sf::Clipboard::setString("This is the first test!");
        if(sf::Keyboard::isKeyPressed(sf::Keyboard::Num2))
            sf::Clipboard::setString(L"Hello world, Καλημέρα κόσμε");

        window.clear();
        window.draw(text);
        window.display();
    }
}

[Ricky]

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.

[eXpl0it3r]

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.

[Tank]

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.

[eXpl0it3r]

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.

[Tank]

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.

[Ricky]

Just updated some stuff on Github. Comments please!

[Ricky]

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?

[Tank]

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

[dabbertorres]

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.

[Laurent]

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.

[sjaustirni]

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.

[Ricky]

Okay so I fixed up the documentation and removed the copy paste errors and the example. Comments?

[Ricky]

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 

[Phanoo]

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