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

[Jeremy Huddleston]

We want to avoid "when switching fg/bg" because this causes unexpected  
bahavior when using pbcopy/pbpaste (the expected behavior would be  
that pbpaste should paste whatever was just copied via cmd-c)


On Sep 12, 2008, at 05:31, Derek Fawcus wrote:

> 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
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3040 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20080912/3db624ab/attachment.bin