On Sep 23, 2008, at 06:55, Derek Fawcus wrote:
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.
It would only be disabled if there were no handlers, so if you disabled that option for pbproxy and you had your own handler, it should still show up as enabled.
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.
There is no PRIMARY->CLIPBOARD copying. What do you mean by "that menu"? It's embedded in the server (as in that's where the bits are), but it's just like any other X11 client (like it is now with the bits separate). Toggling that main checkbox just toggles whether or not that thread is active... so you could just as easily disable it and use another option.
Or would 'Enable Syncing' selected, with everything else deselected allow what I desire - the ability to run an external pbproxy equivalent?
Enabling that and disabling everything else would cause the 'copy' menu item to be handled by pbproxy. You want to disable the 'Enable syncing' option.
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.
Yes.
However I believe it should be possible to seperate the CLIPBOARD-
Pasteboard proxying from pbproxy acting as a CLIPBOARD manager.
It is not possible without adding more complicated menu items. Please read through the thread on this list from last week for reasons why and if you're still convinced, I'd welcome your suggestions.
I'm not sure if we need an option to disable updating PRIMARY when Pasteboard changes. Does anyone want this facility?
Yes, I do. In Mail.app, copy URL. In xterm, wget <middle click>.
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.
I just verified that Inkscape does not acquire PRIMARY when it acquires the CLIPBOARD. And even if you were right in most cases, I'd still want to give users the option of just proxying to one or the other.
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.
Well, you have the source code. Go for it. I fail to see how putting the bits into the server and adding an option for running the thread or not will hinder your attempts.
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.
Yes, so people get this proxying even if they don't use quartz-wm. They get it if they use XDMCP to connect to their linux box. They get it if that have a custom .xinitrc and aren't told they should exec this new binary.
Startup for a seperate process is easily handled in the same way that quartz-wm is started (currently the .xinitrc file).
However, your configuration isn't the only one out there. Some people start the server without xinit. Some people have an existing ~/.xinitrc which we can't update (unless they happen to source /usr/ X11/lib/xinit/xinitrc from their ~/.xinitrc. I want to support these other uses. --Jeremy