Clipboard support on Linux: A few hiccups.

[Hiura]

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

[Tank]

@Nexus
Don't you use sf::Window on Android, as well?

[Juhani]

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

[Laurent]

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

[dabbertorres]

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.

[Nexus]

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?

[dabbertorres]

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.

[Nexus]

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

[Juhani]

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

I don't know what you mean by clutter

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.

[Nexus]

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.

[Juhani]

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

[Hiura]

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. 

[Nexus]

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

[Laurent]

Don't forget that this topic was started with an implementation for Windows and Linux (if I remember correctly). Don't restart from scratch

[Nexus]

Thanks! In fact I already had a brief look at Aster's code
Other libraries may of course also serve as inspiration.