Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Clipboard support on Linux: A few hiccups.  (Read 81805 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Clipboard support on Linux: A few hiccups.
« Reply #75 on: October 12, 2014, 09:29:45 pm »
Quote
That's why you need to call CloseClipboard or something.
And how does this explains that the content of the clipboard is still available after the window is closed?
Laurent Gomila - SFML developer

Aster

  • Full Member
  • ***
  • Posts: 130
    • View Profile
Re: Clipboard support on Linux: A few hiccups.
« Reply #76 on: October 12, 2014, 11:38:19 pm »
Quote
That's why you need to call CloseClipboard or something.
And how does this explains that the content of the clipboard is still available after the window is closed?

After a bit of reading..

Although MSDN doesn't specify how clipboard ownership works, it does specify that the clipboard can contain data even if it has no owner. I couldn't find anything on the internals of this, but ownership of the clipboard is given when EmptyClipboard is called, and that's pretty much it. You lost it when EmptyClipboard is called by another window.

There are GetClipboardOwner functions, but I'm not sure what they're for.

Juhani

  • Newbie
  • *
  • Posts: 28
    • View Profile
Re: Clipboard support on Linux: A few hiccups.
« Reply #77 on: October 12, 2014, 11:40:53 pm »
If SetClipboardData succeeds, the system owns the object identified by the hMem parameter.
« Last Edit: October 12, 2014, 11:44:28 pm by Juhani »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Clipboard support on Linux: A few hiccups.
« Reply #78 on: October 13, 2014, 07:55:01 am »
So, if I understand correctly, on Windows, you can't set clipboard data if it's not owned by a window, but if the owner window disappears then the clipboard data remains valid? This doesn't make any sense :-\
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: Clipboard support on Linux: A few hiccups.
« Reply #79 on: October 13, 2014, 07:56:46 am »
Yeah, EmptyClipboard would fail if you called it without being the owner. Not the first time that the WinAPI is confusing. ;)

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: Clipboard support on Linux: A few hiccups.
« Reply #80 on: October 13, 2014, 09:11:08 am »
So, if I understand correctly, on Windows, you can't set clipboard data if it's not owned by a window, but if the owner window disappears then the clipboard data remains valid? This doesn't make any sense :-\

No. You'll essentially have to open/lock the clipboard to get write access. You then pass in an object, which is overtaken by the system (so you're no longer allowed to directly modify or free it). You close the clipboard and you're done. You don't have to handle ownership or anything and you don't have to track your data (if you don't want to). Ownership here is basically just about who's allowed to free some (shared) memory.

However, there's some way to intercept clipboard requests to pass more advanced/custom data (e.g. not just plain text), which is something you might have seen done by Microsoft Office. For example, if you copy lots of text and close Word, it will ask you whether you'd like to keep your clipboard contents (since it's then passing off ownership).

Aster

  • Full Member
  • ***
  • Posts: 130
    • View Profile
Re: Clipboard support on Linux: A few hiccups.
« Reply #81 on: October 13, 2014, 09:26:05 am »
Yeah, EmptyClipboard would fail if you called it without being the owner. Not the first time that the WinAPI is confusing. ;)

EmptyClipboard sets the owner. As Juhani said, the contents of the clipboard are owned by the system, not the window, when SetClipboardData is called, which is why you don't delete them during cleanup.

Aster

  • Full Member
  • ***
  • Posts: 130
    • View Profile
Re: Clipboard support on Linux: A few hiccups.
« Reply #82 on: October 20, 2014, 06:42:15 pm »
So.. no conclusion?
Now that we've been through the internals, is the current API suitable?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Clipboard support on Linux: A few hiccups.
« Reply #83 on: October 20, 2014, 08:30:11 pm »
I proposed an alternative API, and although nobody seemed to be against it, there was no explicit comment about it, so... I'm like you, waiting.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Clipboard support on Linux: A few hiccups.
« Reply #84 on: October 20, 2014, 08:38:32 pm »
How would the implementation look on other systems -- OS X, iOS, Android?

Does the use of XCB instead of raw X11 change anything?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Aster

  • Full Member
  • ***
  • Posts: 130
    • View Profile
Re: Clipboard support on Linux: A few hiccups.
« Reply #85 on: October 20, 2014, 08:43:36 pm »
How would the implementation look on other systems -- OS X, iOS, Android?

Nor OSX, nor Android require a window handle to use the clipboard as far as I know.
No clue for iOS.

Does the use of XCB instead of raw X11 change anything?

No.

Juhani

  • Newbie
  • *
  • Posts: 28
    • View Profile
Re: Clipboard support on Linux: A few hiccups.
« Reply #86 on: October 20, 2014, 11:49:10 pm »
The current API (member function) is fine with me. Concerning Laurent's concern of possibly giving a false impression that each window would store its own clipboard data, I think it could be solved by just calling the member functions more appropriately: seizeClipboard(sf::String) and String readClipboard(), to reflect that the clipboard isn't a sf::Window field.
But if there are good reasons for a non-member approach, then what Laurent suggested is also fine with me:

class Clipboard
{
    static data get(window?);
    static void set(data, window);
}
 

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: Clipboard support on Linux: A few hiccups.
« Reply #87 on: October 21, 2014, 01:47:20 am »
I have nothing against either a member function or a static function (but I still think a member function is best). I would just have an issue with making a dedicated class like sf::Clipboard that would presumably end up in the system module. What happens if we want to support more MIME types such as images? Then we would have to have the system module rely on the graphics module for the sf::Image type which would then lead to a circular dependency issue. If we keep it as part of the window class then we can provide overloads of the get/setClipboard function to support images within the clipboard.
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Clipboard support on Linux: A few hiccups.
« Reply #88 on: October 21, 2014, 07:45:57 am »
Quote
but I still think a member function is best
Why?

Quote
What happens if we want to support more MIME types such as images?
The system must be flexible enough to support external handlers for other MIME types. So the base implementation should only deal with raw data (text) and provide a way to plug other conversion handlers that would work on top of this raw data.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Clipboard support on Linux: A few hiccups.
« Reply #89 on: October 21, 2014, 09:41:13 am »
I'm definitely in favor of a sf::Clipboard class. With it, there have been two proposals:
static void copyText(sf::Window& window, const sf::String& text);
static sf::String pasteText(sf::Window& window);
or
static void copyText(const sf::String& text);
static sf::String pasteText();

It seems like the main argument for the first one is that it simplifies the implementation and does not require a dummy window when there is none, while the second one simplifies the usage and does not pull implementation details to the API. It's also not clear what the window parameter would do on systems that have a truly global clipboard (it would obviously do nothing, but requiring it nonetheless is user-unfriendly) and how the semantics of the window could be explained in a portable way.

By the way, instead of generic "setText" and "getText" methods, I would probably call them "copy" and "paste" or "copyText" and "pasteText". Or maybe "string" instead of "text", to make sure we refer to sf::String and not sf::Text.
« Last Edit: October 21, 2014, 09:43:21 am by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

 

anything