[GRASS5] Re: [bug #4155] (grass) d.m will not display remotely

[Kirk R. Wythers]

Thanks for your thoughts on this issue Glynn. Here is the answer (for  
the purposes of the archives).

On OS X (Tiger 10.4) use ssh -Y, (which enables trusted forwarding).  
and the Wish shell (built on X11 forwards fine).

Panther and earlier used a version of ssh that only used the -X  
option for X forwarding. This should probably go somewhere in the  
wiki as well. I will write it up if someone can suggest a location  
that makes sense.

Kirk

On Mar 11, 2006, at 7:34 PM, Glynn Clements wrote:

>
> Kirk R. Wythers wrote:
>
>>> The problem applies to running wish (the Tcl/Tk interpreter), and  
>>> will
>>> affect all Tcl/Tk programs. There isn't anything that d.m or  
>>> gis.m can
>>> do to work around it.
>>
>> Can you enlighten me as why with wish shell would work fine locally,
>> but not remotely. I want to think this through because I am guessing
>> that there is some odd OS X thing going on here.
>
> There are two possibilities that I can think of, but both are really
> just wild guesses.
>
> 1. Your version of Tk relies upon additional pre-defined atoms which
> are specific to the MacOSX X server.
>
> 2. It is communicating with both local and remote X servers, and using
> XIDs obtained from one on the other.
>
> It's conceivable that the latter might come about due to some form of
> integration between Aqua and X, e.g. clipboard integration. If Aqua is
> trying to pass XIDs from the local X server to wish, and wish is
> passing them to the remote X server, that isn't going to work.
>
> Some background:
>
> An atom is a "registered" string which can be referenced by an integer
> XID. There are a set of pre-defined atoms (listed in the X11/Xatom.h
> header file), but applications can register additional atoms using
> XInternAtom[s]. Atoms are shared by all X clients on a given server.
>
> Atoms are used for inter-client communication. Rather than passing
> strings such as "CLIPBOARD", clients obtain the XID corresponding to
> that string then pass the XID. This reduces traffic and simplifies
> comparisons (integer comparison rather than string comparison).
>
> Apart from the pre-defined atoms, the X server allocates atoms in
> order, so the XID for a given atom will depend upon when it was
> created. Consequently, the XIDs will vary between server instances.
>
> If an application can have connections to multiple X servers (XEmacs
> supports this), it has to remember separate XIDs for each X server.
> E.g. the XEmacs instance I'm using to compose this message is running
> on a Linux box, with connections to both the local X server and a
> remote X server on a Windows box. On the local X server, the XID for
> the CLIPBOARD atom is 372, while on the remote X server it is 218.
>
> -- 
> Glynn Clements <glynn at gclements.plus.com>
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5