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