Clipboard support on Linux: A few hiccups.

[Laurent]

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.

[Aster]

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.

[Nexus]

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.

[Laurent]

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);
};

[Aster]

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.

[Laurent]

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

[Aster]

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

[Laurent]

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.

[Aster]

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.

[eXpl0it3r]

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

[Aster]

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

[Laurent]

And don't worry, it won't get lost just because it is not merged

[Aster]

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.

[Ruckamongus]

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?

[Laurent]

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.