[Xquartz-dev] Proposal for PRIMARY and CLIPBOARD Copy/Paste

[George Peter Staplin]

Quoted Derek Fawcus <dfawcus at cisco.com>:

> On Thu, Sep 11, 2008 at 06:58:07PM -0600, George Peter Staplin wrote:
>>
>> How do you detect the selection when not every toolkit will set the
>> selection owner when text changes?  I think it's asking for trouble to
>> have every toolkit set the owner after a change.  We'd have to
>> probably patch Tk, Motif, and lots of legacy apps.  Some of which may
>> be compiled statically and running remotely...
>
> I've not tried it with code yet,  but the documentation I've read for the
> pasteboard suggests it can operate in two modes,  one of which is similar
> to how X selections work.
>
> 1) Synchronous copy - pasteboard immediately updated
> 2) Asynchronous reservation - a 'promise' is put on the pasteboard,  and a
>    form of callback is invoked when some other client tries to copy data
>    off the pasteboard.
>
> So assume pbxproxy is a seperate add (just makes some cases easier).
>
> It would probably connect to the Window server (i.e. using Cocoa stuff),
> and seperately to the X server (maybe a private channel t X server).
>
> It probably also needs to know when the X server becomes a background
> app from OSX pov,  so that switching between OSX apps and X apps can
> be detected.
>
> Then:
>   If X app in forground:
>     If CLIPBOARD selection updated,  run the selection protocol to
>     copy the contents to pbxproxy (for simple data types),  and note
>     that we have new contents.
>
>     If PRIMARY selection updated,  note that someone else owns primary.

The thing is we can't know if the PRIMARY has really been updated --  
only if the owner changes.  That's another constraint that makes this  
really unsolvable.  The really ugly solution might be to pull the data  
from the owner periodically, but that sounds uglier than just  
violating one HIG to fix this issue.

>   When X goes to background:
>     If new clipboard has new contents,  or primary has new contents
>       then run async PB sequence to request a callback.
>
>   While in background,  and if get PB async callback:
>     If primary has new contents (and some run time config option to prefer
>       primary) provide it to pasteboard,  else if clipboard has new data
>       provide it to pasteboard.  This may involve using the selection
>       protocol to grab contents and converting.  Now use sync PB sequence
>       to place same data in pasteboard w/o getting subsequent callbacks
>       (for only some or all possible data forms?).
>
>   Then when X goes to foreground:
>     If pasteboard has changed,  note that our copy of clipboard data is
>       out of date,  and take CLIPBOARD selection.  Optionally take PRIMARY
>       selection as well based on some run time config option.
>
>   When asked to provide data from X selection protocol:
>     If we previously noted that the pasteboard contents changed on going to
>       foreground then use PB APIs to provide data for X selection protocols.

I don't think this solves the ambiguity.  XQuartz copy and paste is  
going to require setting an option I guess if you want CLIPBOARD.

> This should then provide a somewhat different approach to copying,  where
> explicit copy/paste actions (menus,  hot keys etc) result in CLIPBOARD being
> used and it consider the main data path.  But if one sweeps and clicks to
> select/paste (xterm) it is used.
>
> The CLIPBOARD approach will be robust in that data (in someform) is   
> guarenteed
> to be copied when the explicit copy action is performed,  and it can even
> survive the program crashing/exiting.  Whereas PRIMARY is the 'power user'
> approach which still has the possibily of data loss on crash.
>
> We then more or less use CLIPBOARD in a similar fashion to how   
> macos, windows,
> and various toolkits do,  while allowing those who prefer PRIMARY (me) to be
> comfortable.
>
> DF

At this point I'd settle for 1 new menu item -- "Copy Clipboard."  We  
could make Paste own PRIMARY and CLIPBOARD and it would all work  
without ambiguity...

George
-- 
http://www.xmission.com/~georgeps/  http://whim.linuxsys.net
http://code.google.com/p/megapkg/