SFML community forums

General => Feature requests => Topic started by: FRex on July 16, 2013, 04:33:48 pm

Title: Clipboard and open with default application support
Post by: FRex on July 16, 2013, 04:33:48 pm
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.
Title: Re: Clipboard and open with default application support
Post by: Laurent on July 16, 2013, 04:57:06 pm
Quote
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.
Title: Re: Clipboard and open with default application support
Post by: FRex on July 16, 2013, 05:10:53 pm
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?
Title: Re: Clipboard and open with default application support
Post by: Haze on July 16, 2013, 06:13:47 pm
I remember this feature has already been requested quite early in SFML history. See previous threads:
[Clipboard Support] (http://en.sfml-dev.org/forums/index.php?topic=474)
[cross platform clipboard support?] (http://en.sfml-dev.org/forums/index.php?topic=1112.0)

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 (https://github.com/glfw/glfw/blob/11a27de3d3b28dd3d0b6ece1a83a409f4058bc95/src/win32_clipboard.c#L42)
Cocoa implementation @github (https://github.com/glfw/glfw/blob/11a27de3d3b28dd3d0b6ece1a83a409f4058bc95/src/cocoa_clipboard.m#L40)
X11 implementation @github (https://github.com/glfw/glfw/blob/0463e196b408f49ff2a0fd722da430d7cc85d40d/src/x11_clipboard.c#L257)
Title: Re: Clipboard and open with default application support
Post by: Laurent on July 16, 2013, 08:08:55 pm
Ok, I'll think about these features, I promise. But they are not on top of my priority list.
Title: Re: Clipboard and open with default application support
Post by: Rosme on July 17, 2013, 12:43:49 am
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.
Title: Re: Clipboard and open with default application support
Post by: FRex on July 17, 2013, 01:47:55 am
Quote
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.

Quote
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.
Title: Re: Clipboard and open with default application support
Post by: Marukyu on July 19, 2013, 01:30:14 am
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.
Title: Re: Clipboard and open with default application support
Post by: FRex on July 19, 2013, 01:43:47 am
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).
Quote
"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.
Title: Re: Clipboard and open with default application support
Post by: Juhani on June 03, 2014, 03:28:13 am
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.
        }
}
Title: Re: Clipboard and open with default application support
Post by: Jesper Juhl on June 03, 2014, 09:10:02 pm
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?
Title: Re: Clipboard and open with default application support
Post by: Juhani on June 03, 2014, 10:54:04 pm
Quote from: Jesper Juhl on June 03, 2014, 09:10:02 pm
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.
Title: Re: Clipboard and open with default application support
Post by: Jesper Juhl on June 07, 2014, 11:50:41 pm
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.
Title: Re: Clipboard and open with default application support
Post by: Juhani on June 08, 2014, 04:42:06 pm
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'.
Title: Re: Clipboard and open with default application support
Post by: Ixrec on June 08, 2014, 04:55:38 pm
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.
Title: Re: Clipboard and open with default application support
Post by: Jesper Juhl on June 08, 2014, 04:58:56 pm
That sounds reasonable to me (the paste event thing).
But what if the user wants to stuff something into the clipboard? Stuff it into PRIMARY? CLIPBOARD? Both? Should the user be able to choose?
Title: Re: Clipboard and open with default application support
Post by: zsbzsb on June 08, 2014, 05:09:31 pm
For reference, Aster (Mischa-Alff) was working on clipboard support. His repository is here (https://github.com/Mischa-Alff/SFML).
Title: Re: Clipboard and open with default application support
Post by: Juhani on June 09, 2014, 12:26:01 am
Quote from: Jesper Juhl on June 08, 2014, 04:58:56 pm
That sounds reasonable to me (the paste event thing).
But what if the user wants to stuff something into the clipboard? Stuff it into PRIMARY? CLIPBOARD? Both? Should the user be able to choose?

The best service for the user would be letting him choose which clipboard to overwrite, which would normally be determined by key bindings: ctrl+c for CLIPBOARD and selection for PRIMARY. Always overwriting both clipboards would be an annoyance to the user, especially if he doesn't expect it.
Title: Re: Clipboard and open with default application support
Post by: Ixrec on June 09, 2014, 12:40:44 am
The main problem with that is I don't think the PRIMARY/CLIPBOARD distinction applies to other platforms.  In particular, Windows only seems to have one clipboard period (the documentation I read even implied that you take ownership of the clipboard by emptying what's currently in it).  Mac OS seems to have a separate "pasteboard" for drag and drop content, but still only one pasteboard for the traditional copy/paste behavior we're interested in.  So I don't know if there is any sensible cross-platform interface that could expose this PRIMARY/CLIPBOARD distinction.

But does it even matter?  I've never felt the need to perform multiple copies and then multiple pastes, as opposed to multiple copy-pastes.  It's not like that enables anything that isn't already possible with copy-pastes through a single clipboard.  Is there any real need to support this use case, or is it just a neat trick that Linux offers but no one else cares about?
Title: Re: Clipboard and open with default application support
Post by: Jesper Juhl on June 09, 2014, 12:48:26 am
As far as SFML goes I guess you can call it "a neat trick that noone cares about" - and I personally won't mind.
When it comes to actual usage, then I think you'll find that many *NIX users care about how their clipboards behave and expect certain things. I don't think I'm the only one to be accustumed to multiple clipboards.
But, as far as SFML goes, a clipboardPaste event that triggers no matter which clipboard you paste from would be just fine (IMHO).
And, if we want to let the user stuff something into the clipboard, then letting that just be into PRIMARY would work for most people (or maybe PRIMARY and also CLIPBOARD).
For what SFML is doing it's not hugely important, so if we just implement something basic it's likely to be good enough (at least for starters).
Title: Re: Clipboard and open with default application support
Post by: Ixrec on June 09, 2014, 07:58:24 am
I guess we could simply have the setClipboard function take an optional sf::Clipboard::Implicit/Explicit parameter saying whether the user explicitly triggered this copy or not, then the platform-specific code can decide whether to do anything with that.

Perhaps more important is whether we should try to support data types other than simple text.  At the very least whatever API gets used should definitely allow for this extension, even if at first sf::Clipboard::Text and sf::Clipboard::Any (which returns the raw data) are the only supported data types.  In an ideal world the various kinds of image data different clipboards support could be passed directly to sf::Texture::loadFromMemory, but I have no idea how feasible that is (still don't have the time to investigate this stuff myself =( ).
Title: Re: Clipboard and open with default application support
Post by: Nexus on June 09, 2014, 10:07:52 am
I don't know whether SFML should take care of all those Unix-specific clipboards. After all, it abstracts from operating systems and tries to show the same behavior on all platforms. I also think the "PRIMARY" clipboard with selection and middle mouse key is rather used within the same application, than between different applications.

So... why not simply provide the "CLIPBOARD" one with Ctrl+C and Ctrl+V, as it will be provided on other platforms?
Title: Re: Clipboard and open with default application support
Post by: Juhani on June 09, 2014, 12:39:14 pm
Using the CLIPBOARD would also allow adding support for PRIMARY later without changing the clipboard interface.

Concerning the suggested paste Event, it occurred to me that the user might want to bind the middle-mouse or ctrl+v to something else in a context where clipboard isn't needed (such as in a FPS game). Then SFML would be reading the clipboard needlessly to produce the paste Event (which would be ignored).
Title: Re: Clipboard and open with default application support
Post by: select_this on June 09, 2014, 12:41:03 pm
I'm not a fan of the middle mouse button clipboard, personally - I always disable it because I'm clumsy and often accidentally end up pasting stuff. I'd be happy with just ctrl-c ctrl-v if I ever needed clipboard functionality.
Title: Re: Clipboard and open with default application support
Post by: Aster on September 08, 2014, 03:21:51 am
Quote from: zsbzsb on June 08, 2014, 05:09:31 pm
For reference, Aster (Mischa-Alff) was working on clipboard support. His repository is here (https://github.com/Mischa-Alff/SFML).

I am indeed working on clipboard support. The link is here, rather (https://github.com/Mischa-Alff/SFML/tree/feature/clipboard). Win32 support is already implemented. Linux is a bit more complicated and I'd like to do it right instead of having some hacked together code. (By "a bit", I mean "Oh God my eyes are bleeding why did I ever commit to doing this?!")

We could handle all the Linux cut buffers/clipboard/selections etc, but honestly, it's not worth it. I'm settling on using X11 selections (or whatever they're called, it's late) because they work pretty much everywhere, and that's what everyone else uses.

I'd be a bit more enthusiastic about Linux support, but my ArchLinux drive died (after ten years of service), and I'm waiting for a new SSD to get delivered to move back to using Arch again. For what I've looked at so far, it might be worth having a clipboard event that's only handled internally, but I'll have to see how I should work with that.

The API is:
There's an example in examples/clipboard in case you want to test it out.

Also, on handling multiple MIME types, zsbzsb suggested we overload the function in sf::RenderWindow for image support. I'm still hesitant about this. If you want to use multiple MIME types in the clipboard, chances are what SFML will provide isn't enough, and you'll end up extending it yourself anyways.

Cheers.