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/clipboards-spec/clipboards-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
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/software/UTF8_STRING/UTF8_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
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 \x, \u, or the like. Incidentally, snarfer is still broken in this manner. -- Kris Maglione If at first you don't succeed, try something else. pgpwqGurMiqvO.pgp Description: PGP signature
[9fans] Mac p9p snarf buffer
snarf'ed content is not passed between mac apps and p9p apps. is it a xdarwin problem?
Re: [9fans] Mac p9p snarf buffer
are you running a current p9p? it didn't used to be, but has been for quite some time. there's a program called 'snarfer' that used to be needed, but it's not running on my system. are you using a window manager other than quartz-wm? if so, you'll need to run: 'quartz-wm --only-proxy ' before starting your wm to bridge the x11/quartz snarf buffers. anthony
Re: [9fans] Mac p9p snarf buffer
On 5/3/07, Skip Tavakkolian [EMAIL PROTECTED] wrote: snarf'ed content is not passed between mac apps and p9p apps. is it a xdarwin problem? It is if you ask it to be. Use the copy command in X to move the data out. Or you can do it automatically; rsc has a program somewhere that runs as a daemon doing the copy for you. -rob
Re: [9fans] Mac p9p snarf buffer
snarf'ed content is not passed between mac apps and p9p apps. is it a xdarwin problem? yes, but i fixed it (by writing directly to the apple clipboard) last year. if you have a program called $PLAN9/bin/devdraw then you should not be having this problem. russ
Re: [9fans] Mac p9p snarf buffer
On 5/3/07, Rob Pike [EMAIL PROTECTED] wrote: On 5/3/07, Skip Tavakkolian [EMAIL PROTECTED] wrote: snarf'ed content is not passed between mac apps and p9p apps. is it a xdarwin problem? It is if you ask it to be. Use the copy command in X to move the data out. Or you can do it automatically; rsc has a program somewhere that runs as a daemon doing the copy for you. -rob When I was using acme all the time, so I'd just select the text I need and then Edit it out to pbcopy. Then it's in the clipboard for whatever else should need it.
Re: [9fans] Mac p9p snarf buffer
The snarf issue that bothers me most these days is that the plan9port programs, at least on the mac, don't handle UTF-8 in the snarf buffer correctly. UTF-8 going out turns into junk; going in it turns into question marks. -rob
Re: [9fans] Mac p9p snarf buffer
if you have a program called $PLAN9/bin/devdraw then you should not be having this problem. i do, and i am, pradoxically ☺ i tried snarfer -v, same result. i'm running xdarwin 1.4a1 (xfree86 4.5.0)
Re: [9fans] Mac p9p snarf buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The right answer is for someone motivated (it won't be me until late summer, I'm afraid) to take the OS X native drawterm back end and drop it into p9p. And maybe fix the couple of bugs left in there (changing screen resolution confuses it because the window resize routine doesn't block to the plan 9 desktop size, and the wnidow-on- top code is borked, making drawterm sit on top of the spotlight pulldown, for example). Paul On May 3, 2007, at 10:52 AM, Rob Pike wrote: The snarf issue that bothers me most these days is that the plan9port programs, at least on the mac, don't handle UTF-8 in the snarf buffer correctly. UTF-8 going out turns into junk; going in it turns into question marks. -rob - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGOiVEpJeHo/Fbu1wRAvSHAJ0XuMNcxYwW0JQn25UevrZr84gE2wCglTms qTDsRzjsxgmgHMLBAHhhV0w= =P3Eo - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGOiVNpJeHo/Fbu1wRAuUaAJ4rzuS5eoo4WvJWf9tESn33plSUMACgjxyV SJ7Xdt56CDFJxRyCngvLdss= =9npk -END PGP SIGNATURE-
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
Re: [9fans] Mac p9p snarf buffer
On Thu, May 03, 2007 at 10:52:26AM -0700, Rob Pike wrote:
The snarf issue that bothers me most these days is that the
plan9port programs, at least on the mac, don't handle UTF-8
in the snarf buffer correctly. UTF-8 going out turns into junk;
going in it turns into question marks.
Yes, this bothered the hell out of me, too. I fixed my copy of
devdraw(1) to ask for a UTF8_STRING before a STRING, as suggested by the
comment, which seems to imply that the extra polling is not worth the
effort:
* We should try to go for _x.utf8string instead of XA_STRING,
* but that would add to the polling.
I hacked this together in about a minute, so it's not beautiful, but it
works.
$PLAN9/src/cmd/devdraw/x11-itrans.c:439:
prop = 1;
data = nil;
XChangeProperty(_x.display, _x.drawable, prop, _x.utf8string, 8, PropModeReplace,
(uchar*), 0);
XConvertSelection(_x.display, clipboard, _x.utf8string, prop,
_x.drawable, CurrentTime);
XFlush(_x.display);
lastlen = 0;
for(i=0; i10 || (lastlen!=0 i30); i++){
usleep(100*1000);
XGetWindowProperty(_x.display, _x.drawable, prop, 0, 0, 0,
AnyPropertyType,
type, fmt, dummy, len, data);
if(lastlen == len len 0)
break;
lastlen = len;
}
if(lastlen == 0) {
XChangeProperty(_x.display, _x.drawable, prop, XA_STRING, 8,
PropModeReplace, (uchar*), 0);
XConvertSelection(_x.display, clipboard, XA_STRING, prop,
_x.drawable, CurrentTime);
XFlush(_x.display);
lastlen = 0;
for(i=0; i10 || (lastlen!=0 i30); i++){
usleep(100*1000);
XGetWindowProperty(_x.display, _x.drawable, prop, 0, 0,
0, AnyPropertyType,
type, fmt, dummy, len, data);
if(lastlen == len len 0)
break;
lastlen = len;
}
}
if(lastlen == 0)
goto out;
--
Kris Maglione
pgpGmxbuCydH7.pgp
Description: PGP signature
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. pgpfonwWl0uVR.pgp Description: PGP signature
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.
Re: [9fans] Mac p9p snarf buffer
Yes, this bothered the hell out of me, too. I fixed my copy of devdraw(1) to ask for a UTF8_STRING before a STRING, as suggested by the comment, which seems to imply that the extra polling is not worth the effort: This is now fixed in the latest CVS, as is the other direction (a completely different fix, of course). Russ
