[Xquartz-dev] pbproxy - a copy/paste proxy for XQuartz

[Derek Fawcus]

On Mon, Sep 22, 2008 at 09:35:11PM -0700, Jeremy Huddleston wrote:
> 
> Did you not see the screenshot in my email?

No - I'm using mutt to read email,  it is a pain to save graphical
attachments,  then find display them.  Hmm - time to config some
more handlers.

Anyway,  I've now seen the picture.

I do not believe the 'copy menu item' should be disabled at the same
time as any internal selection/pasteboard handling.  This would seem
to prevent use of an external pbproxy ala the current offering.

>From nm on pbproxy,  it seems that a WM extension symbol is being used
for triggering the PRIMARY->CLIPBOARD copying and subsequent copying to
pasteboard.  I assume that 'Enable Syncing' would disable that menu and
hence if the pbproxy functionality was embedded in the server,  prevent
the use of an external pbproxy.

Or would 'Enable Syncing' selected,  with everything else deselected allow
what I desire - the ability to run an external pbproxy equivalent?

As to the 'Update Pasteboard when CLIPBOARD changes' option.  As written
this seems to imply that pbproxy will always act as a CLIPBOARD manager
and take ownership of the CLIPBOARD selection after it has been changed.
However I believe it should be possible to seperate the CLIPBOARD->Pasteboard
proxying from pbproxy acting as a CLIPBOARD manager.

I'm not sure if we need an option to disable updating PRIMARY when
Pasteboard changes.  Does anyone want this facility?

All X apps will (I believe) acquire PRIMARY when they acquire CLIPBOARD,
and so this would always be enabled.  So I suspect these two should be
combined in to a single 'Update PRIMARY and CLIPBOARD when Pasteboard changes'
option.

> >This way the behaviour is easily changeable.
> 
> How do you mean?

Assume I want to extend its capabilities.  e.g. add support for other
target atoms <-> pasteboard UTIs,  perform data transformations,  etc.

> >Also it allows for better bug isolation if something goes wrong,
> >which it might if the code starts to do complex data manipulation.
> 
> well it's on a separate thread and doesn't actually mangle any data.   
COMPOUND_TEXT <-> UTF8 (but probably using the X library code)
> The other thread would just be an X11 client thread and the  
> communication between threads would still be X11 events (atleast for  
> now).

Embedding it in the server, as described above,  seems to gain little.
We move from the existing,  cut'n'paste fixed in quartz-wm,  to cut'n'paste
fixed in server.

The only possible reason I can see to embed it in the server is to reduce
context switch latencies,  which compared to the data copying,  and the
context switches which cannot be eliminated (esp. if INCR occurs) seems
a minor consideration.  I believe pastboard promises can be used to defer
copying (X11->pasteboard) until such time as pasting on the OSX side is
attempted.

Startup for a seperate process is easily handled in the same way that
quartz-wm is started (currently the .xinitrc file).

DF