Re: [9fans] Mac p9p snarf buffer - Plan9

This is a discussion on Re: [9fans] Mac p9p snarf buffer - Plan9 ; I made some X fixes that solve at least half the problem Rob reported. cd $PLAN9/src/cmd/devdraw; mk install; mk clean on the machines where the apps are running (which might not be the Mac if you are using ssh -X ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Re: [9fans] Mac p9p snarf buffer

  1. Re: [9fans] Mac p9p snarf buffer

    I made some X fixes that solve at least half the problem Rob reported.

    cd $PLAN9/src/cmd/devdraw; mk install; mk clean

    on the machines where the apps are running (which might not
    be the Mac if you are using ssh -X to run remote X apps).

    I have no good answer for Skip's problem -- X11 shouldn't even
    be involved. The rest of this mail is an explanation of the
    various problems.

    There are many different moving parts here, and each configuration can
    produce a different failure (or success).


    + X11 selections v. Pasteboard

    X11 doesn't have a snarf buffer. Instead it has an idea of which
    window currently "owns" the snarf (X11 would say `selection'), and
    when you want to find the snarf contents you go ask the current owner.
    There is no central buffer like on Plan 9's /dev/snarf or the Windows
    clipboard. (In addition to making things a lot more complicated, this
    means that snarf contents do not persist once their owner exits. But
    that particular problem isn't relevant here.)

    OS X does have a snarf buffer, called the Pasteboard. There are
    programs pbcopy and pbpaste that come with OS X that write to and read
    from the Pasteboard.

    The OS X X11 server has the unenviable task of making the X11 madness
    interoperate with native OS X. As far as the snarf buffer is
    concerned, it's job should be to synchronize in both directions:

    * Every time an OS X app writes to the pasteboard, X11 should claim
    to own the snarf, and when apps request the snarf from it, it should
    serve the request using the pasteboard contents.

    * Every time an X11 app claims the snarf, X11 should fetch the snarf
    from it and write to the pasteboard.

    Bug #1: some versions of the OS X X11 server require you to select
    "Copy" from the X11 Edit menu before fetching the snarf and writing it
    to the pasteboard.

    To work around bug #1, p9p apps on OS X write directly to the
    pasteboard themselves rather than depend on the X11 server. nm
    $PLAN9/bin/devdraw | grep Pasteboard should confirm this.

    Unfortunately, this workaround does not work when running an app on a
    remote machine via ssh -X. Then the only connection to the local
    pasteboard is via X11 so apps are at its mercy.


    + X11 selection updates

    As best I can tell, if you own the snarf then another app can send you
    an XSelectionRequest request, which turns into an
    XSelectionRequestEvent event. Then you copy the snarf into a public
    attribute on the X11 server using XChangeProperty and use XSendEvent
    to send an XSelectionEvent to the requestor (the id is in the initial
    request) to tell it that the snarf is ready.

    Bug #2. On OS X using ssh -X forwarding, the X11 server does not let
    the final XSendEvent run. Instead it returns with an error and the
    app often gives up. I was trying this with "X11 1.1.3 - XFree86
    4.4.0", ssh -X to Linux, and then running xterm or gtkedit or leafpad,
    and they all crashed after the server rejected one message or another.
    So remote apps seem not to be very reliable in some versions of X11 on
    OS X.


    + X11 selection formats

    X11 allows (nay, encourages) selections to be arbitrary blocks of
    data. When you fetch the snarf from an owner, the first thing you do
    is ask for a list of possible formats. Then you look in the format
    list for one that sounds good to you. The most common is "STRING".
    Other apps are free to make up names for other strings. Most seem to
    have standardized on "UTF8_STRING" for a UTF-8 string, though some do
    things like "text/plain;charset=UTF-8".

    Bug #3 (fixed). It had been working okay to respond to all these
    various kinds of strings with UTF-8 data and to ask for plain "STRING"
    and hope it would be UTF-8. Apparently on OS X that is not okay
    anymore -- when you ask for "STRING" from the X11 server it replaces
    non-ASCII characters with ?.

    I changed p9p to try "UTF8_STRING" before trying "STRING", and now
    pasting UTF-8 into p9p apps on OS X works for me.

    I tried to reproduce the "garbage out when copying UTF-8 from p9p to
    OS X" but it works fine for me locally. Because of Bug #2 I can't
    tell whether copying UTF-8 from a remote X11 window to a local OS X
    app produces garbage or not. I changed the returned format list to
    mention "UTF8_STRING" before "STRING", so that apps that request the
    format list (not all do) and look for the first one they like will
    prefer UTF-8.


    + Avoiding X11

    Paul Lalonde suggested using native OS X bindings instead of relying
    on X11. This is a good idea and one that I hope will happen soon,
    but it won't entirely solve the problem. People do run remote
    X apps via ssh -X, and most of the problems (like Bug #3) would
    have eventually cropped up on the other X-based systems if left
    unfixed. So while I encourage having a native OS X devdraw,
    we still need to figure out how to play nice with the OS X X11.

    Russ


  2. Re: [9fans] Mac p9p snarf buffer

    On Thu, May 03, 2007 at 05:20:08PM -0400, Russ Cox wrote:
    >+ X11 selections v. Pasteboard
    >
    >X11 doesn't have a snarf buffer. Instead it has an idea of which
    >window currently "owns" the snarf (X11 would say `selection'), and
    >when you want to find the snarf contents you go ask the current owner.
    >There is no central buffer like on Plan 9's /dev/snarf or the Windows
    >clipboard. (In addition to making things a lot more complicated, this
    >means that snarf contents do not persist once their owner exits. But
    >that particular problem isn't relevant here.)


    As if that weren't bad enough, X11 *also* has central buffers, "cut
    buffers", which are deprecated, but still used by some apps. And there
    are 3 selections, PRIMARY, SECONDARY, and CLIPBOARD. Some apps,
    expecially browsers and Gnome/KDEish apps, tend to use the PRIMARY and
    CLIPBOARD selections, depending on what you're doing (middle click
    pastes the PRIMARY, ^V pastes the CLIPBOARD). It's a terrific mess.

    But let's not sully this list with X11 insanity any more.

    --
    Kris Maglione

    If you lived here you'd be home now.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.3 (FreeBSD)

    iD8DBQFGOneyseQZD8Aui4wRAqEuAKCXT8DUmC2GN/oWsLXIM/k/5yT2XACdFr1U
    SsOL/obh0oRk6w32pN3ZyD4=
    =Ou2z
    -----END PGP SIGNATURE-----


  3. Re: [9fans] Mac p9p snarf buffer

    | X11 doesn't have a snarf buffer. Instead it has an idea of which
    | window currently "owns" the snarf (X11 would say `selection'), and
    | when you want to find the snarf contents you go ask the current owner.
    | There is no central buffer like on Plan 9's /dev/snarf or the Windows
    | clipboard. (In addition to making things a lot more complicated, this
    | means that snarf contents do not persist once their owner exits. But
    | that particular problem isn't relevant here.)

    No, it really does have a CLIPBOARD property, separate from selections
    like PRIMARY. A program like xclipboard or kde's klipper or whatever
    the gnome thing is, maintains this.


  4. Re: [9fans] Mac p9p snarf buffer

    On Thu, May 03, 2007 at 08:00:50PM -0400, Kris Maglione wrote:
    >
    > As if that weren't bad enough, X11 *also* has central buffers, "cut
    > buffers", which are deprecated, but still used by some apps. And there
    > are 3 selections, PRIMARY, SECONDARY, and CLIPBOARD. Some apps,
    > expecially browsers and Gnome/KDEish apps, tend to use the PRIMARY and
    > CLIPBOARD selections, depending on what you're doing (middle click
    > pastes the PRIMARY, ^V pastes the CLIPBOARD). It's a terrific mess.


    There is an attempt underway to get some sanity in use...

    http://standards.freedesktop.org/cli...boards-0.1.txt

    As to cut buffers, there is no agreed data type in them, so one
    cannot know if they are ascii, latin1, utf-8, or something else.

    DF

  5. Re: [9fans] Mac p9p snarf buffer

    On Thu, May 03, 2007 at 05:20:08PM -0400, Russ Cox wrote:
    > + X11 selection formats
    >
    > X11 allows (nay, encourages) selections to be arbitrary blocks of
    > data. When you fetch the snarf from an owner, the first thing you do
    > is ask for a list of possible formats. Then you look in the format
    > list for one that sounds good to you. The most common is "STRING".
    > Other apps are free to make up names for other strings. Most seem to
    > have standardized on "UTF8_STRING" for a UTF-8 string, though some do
    > things like "text/plain;charset=UTF-8".


    ( For anyone interested, there are gory details at
    http://www.pps.jussieu.fr/~jch/softw...F8_STRING.text )

    > Bug #3 (fixed). It had been working okay to respond to all these
    > various kinds of strings with UTF-8 data and to ask for plain "STRING"
    > and hope it would be UTF-8. Apparently on OS X that is not okay
    > anymore -- when you ask for "STRING" from the X11 server it replaces
    > non-ASCII characters with ?.


    That sounds like a bug in the apple stuff. AFAICR "STRING" encoding
    means 8 bit latin1 (8859-1) characters. So unless the apple code is
    complaining about bytes for which there is no 8859-1 character, I'm
    not sure what's happening.

    DF

  6. Re: [9fans] Mac p9p snarf buffer

    On Fri, May 04, 2007 at 01:29:03PM +0100, Derek Fawcus wrote:
    >That sounds like a bug in the apple stuff. AFAICR "STRING" encoding
    >means 8 bit latin1 (8859-1) characters. So unless the apple code is
    >complaining about bytes for which there is no 8859-1 character, I'm
    >not sure what's happening.


    The behavior is undefined if a STRING is not in the 'Host Portable
    Character Set', but it's not the X server which causes the problem, it's
    the owner of the selection which converts it to a STRING from UTF-8. I'd
    guess that most apps use iconv (ick) for the conversion. Some apps give
    you a '?', some give \xXXXX, \uXXXX, or the like.

    Incidentally, snarfer is still broken in this manner.

    --
    Kris Maglione

    If at first you don't succeed, try something else.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.3 (FreeBSD)

    iD8DBQFGO+oHseQZD8Aui4wRAgkQAJ0YTgWGz5JWnhEtR0+PTo TEc+k0EACeIqJE
    UZ3Jh4c3atlvKV2Nr/zx3fM=
    =2GKV
    -----END PGP SIGNATURE-----


+ Reply to Thread