Clipboard and open with default application support

[FRex]

Clipboard support, straightforward, two functions, one returns std::string by value, other takes std::string by const &, set and get text, does nothing and returns empty string if clipboard is unavailable. (UTF-8 preferably)

Opening with default app: you specify a file path(in UTF-8 preferably too..) and it'll open that file like a double click in file browser would, so .txt will default to notepad or whatever has been set as default in system, html will open in current browser, images in editors or image viewers etc. Can do nothing if not available. Maybe with bool returned to specify whether or not it succeeded.

Uses for both are many and api complexity and bloat minimal, plus it adds one or two headers and three functions without changing or taking anything away so it'll not break existing apps.

[Laurent]

Clipboard support, straightforward, two functions, one returns std::string by value, other takes std::string by const &, set and get text, does nothing and returns empty string if clipboard is unavailable. (UTF-8 preferably)

The clipboard is smarter than just text copy-and-paste. It handles MIME types so that, for example, you can't paste in notepad the image that you copied in GIMP.

The API would therefore be more complicated.

[FRex]

Why? It can be just for text(like GLFW does.. ), returning "" if there is non-text in it, clipboard can appear empty like it does to other places that expect text, 'paste' is grayed out in text editors and text areas if there is image in it. Text is (arguably) most important, it's not like there are many serious use cases where something copies screenshots into your clipboard or loads textures from clipboard but copying text is common, it feels almost unnatural when a gui doesn't respond to ctrl-v and ctrl-c because literally everything else on the system does, that feature would enable people to make SFML apps and guis feel more like a first class citizen.

What about opening files in external programs?

[Haze]

I remember this feature has already been requested quite early in SFML history. See previous threads:
[Clipboard Support]
[cross platform clipboard support?]

Well, I've seen Laurent rejecting feature requests with much stronger terms, so maybe there's still hope
Especially since it seems to be quite a popular one.

And thanks to GLFW3, there's a portable, lightweight implementation which can be easily adapted to SFML:
Windows implementation @github
Cocoa implementation @github
X11 implementation @github

[Laurent]

Ok, I'll think about these features, I promise. But they are not on top of my priority list.

[Rosme]

Personnaly, I don't see the usefulness of those feature in SFML. I can see why for the clipboard, but my problem with such a feature is that it force the user of the SFML to follow its implementation.

An exemple: what if when I copy an Image, I want it to return the path of the ressource, instead of an empty string? If SFML set it like that by default, I'd have to overwrite it in some way to make it show what I want. Same goes for every resources or things. I'd say clipboard is much more user-specific than library-specific.

And for default app? It's something that can be easily achieve with installation wizard. Now if you don't have a wizard, it could be useful but I really don't expect a multimedia library to give me something like this. I'd personnaly expect myself to make the function and calls.

[FRex]

I want it to return the path of the ressource, instead of an empty string? If SFML set it like that by default, I'd have to overwrite it in some way to make it show what I want. Same goes for every resources or things. I'd have to overwrite it in some way to make it show what I want.

'Overwrite' what? Just don't use getClipboardString if you want to get an Image , write own function that will return the image/whatever if it's there, it's not like SFML takes the clipboard away from the OS, also not all resources have paths, images copied from browser with 'copy image', things copied from image editors etc.
These two functions would be just for text and NOTHING else, you call them if you expect user to have text for you there(ie. user pressed Ctrl-V while in an edit box) but you are not forced to use it and it doesn't block your access to clipboard.

And for default app? It's something that can be easily achieve with installation wizard. Now if you don't have a wizard, it could be useful but I really don't expect a multimedia library to give me something like this. I'd personnaly expect myself to make the function and calls.

Installation wizard at runtime of a library and pulled in just for one function that probably takes less than 50 lines on each platform?
This feature would be to open folders for user to drop maps/mods/whatever into or to show where his game saves are, open screens and textures for editing and viewing, open config files for editing, open html with documentation and instructions or links in web browser.

[Marukyu]

Text-only clipboard support built into SFML would be extremely useful, right now I have to rely on popen() with xclip on Linux because I can't access X11 events without having to modify SFML's source code, which would force me to readd my changes everytime I update to a newer SFML version (which is currently quite often, due to SFML's frequent feature, bugfix and optimization progression right now, particularly for Linux).

Also, clipboard handling on Linux is generally quite a complicated matter (compared to a trivial single function call on Windows) and appears to require a good understanding of X11.

Regarding usefulness within a multimedia library, I'd say almost every major SFML app uses some kind of widget toolkit, usually written in SFML itself. Most of those involve text input fields, of which Ctrl-V functionality should be expected.
One argument that seems to be brought up often in this context is Qt's clipboard functionality, but there doesn't appear to be a way to use the clipboard functions from the rest of the Qt library without linking the a large part of the library, adding a significant amount of overhead, particularly if you're using a pure SFML GUI system.

"Open with default application"-type functionality support is much easier to implement without having to modify SFML, all it requires is a call to ShellExecute() on Windows and a script such as xdg-open on Linux, and it's not needed quite as often as the clipboard, so it's probably not all that necessary to be added to SFML.

[FRex]

Yep, clipboard is kind of big deal but it'd take little time to code for someone who knows X and WinApi(I don't).

"Open with default application"-type functionality support is much easier to implement without having to modify SFML, all it requires is a call to ShellExecute() on Windows and a script such as xdg-open on Linux, and it's not needed quite as often as the clipboard, so it's probably not all that necessary to be added to SFML.

Yes, that's what I'm doing for myself on linux now.

I'll put here any argument for implementing and use of a clipboard I can remember. I'm kind of passionate in my clipboard desires.

Unreal Ed 2.0(the one for unreal engine 1.x in UT '99, it was using confusing versioning back then) uses clipboard and plain text when you ctrl-v, ctrl-x, ctrl-c a part of the map.

After some checking and googling:
-libRocket can do it
-GWEN can do it
-Qt and GTK+ obviously.. they are the gui libraries
-CEGUI can do it
-Irrlicht can do it
-SDL 2 can do it
-GLFW 3 can do it
-Ogre can't but it's purely a renderer by design, its de facto std gui(CEGUI) can
-wxWidgets can do it
-FLTK can do it
-Java can do it
-C# can do it
-Lua LOVE can't do it

Some of them probably don't actually use the real clipboard(ie. libRocket outside Windows) and I might have made mistakes in the list but still, SFML is the odd one for missing it and this is a hurdle for any GUI based on SFML.

[Juhani]

Add me to the list of those looking for clipboard support (for text at least). It is within the scope of a multimedia library and used a lot, so I'm slightly surprised that it isn't supported yet.

API could be like:

namespace sf
{       namespace clipboard
        {       bool isAvailable(); // Check whether the operating system has a clipboard and it is supported.
                std::string text(); // Return text on the clipboard, "" if empty.
                bool text(std::string); // Try to set clipboard text and tell is it fails.
        }
}

[Jesper Juhl]

Clipboard support is trickier than it seems.
Keep in mind that, in addition to mime type handling, some systems (like Linux/X) have multiple clipboards - so when you get/set clipboard contents, which one are you referring to?

[Juhani]

Clipboard support is trickier than it seems.
Keep in mind that, in addition to mime type handling, some systems (like Linux/X) have multiple clipboards - so when you get/set clipboard contents, which one are you referring to?

You tell me. I don't know much anything of Linux clipboards - that's why I'm requesting a platform independent interface. If I knew those systems I could make my own implementation of it. I don't know how many clipboards there are on Linux, how they differ from one another, which one most people would prefer, or whether they vary depending on the distribution. Of Macintoshes I know even less than of Linux.

The trickiness of the clipboard is the very reason why SFML should provide an interface to it.

[Jesper Juhl]

Here's a link to some info on Linux (really X) clipboards: http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt

In a nutshell there are 3. When you highlight text it automatically gets copied into the "PRIMARY" clipboard and can be pasted with middle mouse button. If you do something like CTRL+C (or equivalent) or (from a menu) select "copy" it gets copied to the second one "CLIPBOARD" and can then be pasted with CTRL+V (or equivalent) even if something new gets highlighted and goes into "PRIMARY". I don't think the "SECONDARY" clipboard is ever actually used as also mentioned in the link above.

It's actually really handy since, let's say, I have a persons name and address "John Doe, Somewhere Street 42" on screen and I need to put that into two input fields, then I highlight "John Doe" and press CTRL+c and it's now in the CLIPBOARD, then I highlight "Somewhere Street 42" and click the address input field and paste the address with the middle mouse from the PRIMARY clipboard. Then I click the name input field and paste with CTRL+v from the CLIPBOARD clipboard.
Once you get used to it it's actually really nice to have multiple clipboards active at once.

Which one should SFML expose (yes, I do think it should only interact with/expose one)? Personally I would prefer PRIMARY since unless I actually need two clipboards I'm in the habit of just highlighting text and pasting with midle mouse somewhere else without ever bothering with pressing CTRL+c/v (since, why should I bother). But that's just me.

[Juhani]

Using PRIMARY would make sense, because in normal use it would be overwritten anyway when highlighting text for the CLIPBOARD (unless the application provides an eccentric manner of selecting text for the CLIPBOARD). The middle-mouse paste may be unknown to users migrating from Windows, but the application should anyway define which clipboard it uses and that could be mentioned there (for ensample: "This editor by the way uses the middle-mouse paste clipboard on Linux."). Actually, I think you'll be more likely understood if you call it 'the middle-mouse paste' rather than 'PRIMARY':
   "This editor uses PRIMARY on Linux"> <What...?

If both clipboards were supported, one of them would need its own interface. In that case, it would make sense to group the CLIPBOARD with Windows clipboard, because they're accessed similarly, and give PRIMARY its own interface, including a function to check whether it exists at all. It could be called mouseSelection, or just 'selection'.

[Ixrec]

Wouldn't it be simpler to have an sf::Event::ClipboardPaste with a "text" member that encapsulates all kinds of pasting?  I don't think the application code should ever have to worry about what kinds of clipboards are supported or which one the user decided to use.

The only disadvantage to a single-event API I can think of is that it overlaps with the lower-level mouse/keyboard events, but we already have a TextEntered event that overlaps with lower-level keyboard events, so this wouldn't be anything new.


P.S.: Anyone know how this works on the Mac?  It looks like https://developer.apple.com/library/mac/documentation/cocoa/Conceptual/PasteboardGuide106/Introduction/Introduction.html might be the reference page for this.