Re: Development Process (Was Re: Security concerns)
Re: Development Process (Was Re: Security concerns)
- Subject: Re: Development Process (Was Re: Security concerns)
- From: "Nathaniel Gray" <email@hidden>
- Date: Mon, 26 Nov 2007 00:24:59 -0800
On Nov 25, 2007 1:53 PM, Jeremy Huddleston <email@hidden> wrote:
>
> On Nov 25, 2007, at 12:05, dp wrote:
> > And just so you know, *my* component really is the most
> > important! :). Cut/past and clipboard sharing being my interest.
>
> Eh... well... this is a big X11-based issue in general... especially
> because X11 has more than one clip-board, so which do you sync with
> and when? I believe the current/Tiger solution was to use Edit->Copy
> to copy the PRIMARY atom and an external copy caused X11's PRIMARY to
> change (at-least this is consistent with the behavior). I'm guessing
> that pasting in Tiger X11 was just the same as middle-click (I don't
> know since I never used it and don't miss it now that it's greyed-
> out). I don't think any syncing was done with CLIPBOARD.
Heh, I just started investigating this stuff myself. CLIPBOARD is in
fact proxied. I relied on this fact extensively as an NEdit user.
Ben posted the code used in QuartzWM:
https://bugs.freedesktop.org/show_bug.cgi?id=13066
This code *almost* works. The only flaws I know of are a) if you use
"Copy" from the X11 app menu once then CLIPBOARD is never proxied
again, and b) it only checks for Aqua pasteboard updates on
gaining/losing focus of X11.app, so if you used pbcopy in an xterm and
then ctrl-v in NEdit it wouldn't work properly because X11 never lost
focus. You really need to poll the aqua pasteboard for reliable
results, unfortunately. [1]
> I honestly think this is a good solution for copy/paste. Perhaps we
> could add items to the Edit menu (as shift-command-{c,v}) for copy/
> paste-to-CLIPBOARD. Would that functionality serve you?
There's really no need for the end-user to deal with CLIPBOARD vs
PRIMARY. Here's my notion of how it should work at a rather high
level. Note that we don't necessarily need to do this in the server
itself -- it should be fine to simply have a client daemon launched in
the xinitrc. Conceptually, all we need is two notifications:
* Aqua Pasteboard changed (Event APC). Like I mentioned, this will
actually have to be polling-based.
* CLIPBOARD changed (Event CC). It may be possible to do this as an X
client without polling, but doing so might break xclipboard and
similar apps. Google CLIPBOARD_MANAGER to get the idea. There's a
succinct summary here: [2].
What to do with the events:
On event APC, we take ownership of CLIPBOARD and PRIMARY, proxying the
Aqua pasteboard to both.
On event CC, we proxy CLIPBOARD to Aqua.
The Edit/Copy menu item in X11.app should just copy PRIMARY to
CLIPBOARD (via a private window), thus causing a CC event to be
generated. After all, that's what "copy" does -- puts the selection
in the clipboard. This doesn't need to be part of the clipboard proxy
process at all.
I don't think this should be a terribly difficult project. Given the
QuartzWM code linked above I would expect it could be done in a
weekend. I'm inclined to do it myself the next time I can find some
time.
Cheers,
-n8
[1] http://www.cocoabuilder.com/archive/message/2004/12/21/124049
[2] http://www.faqs.org/faqs/motif-faq/part9/section-21.html
--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden