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

[Derek Fawcus]

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.

  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.

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