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

[Scott Mitchell]

On 14-Mar-06, at 07:11, Kirk R. Wythers wrote:

> 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).
>

Thanks for that post, Kirk - I am chagrined to realize that I used to  
know this, then managed to forget it for a few months.  So I have  
been needlessly limiting myself to only running GRASS locally/non- 
graphically until I could find time to delve into it, but you have  
fixed it for me!

> 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.
>

Perhaps the tips & tricks section of the Wiki?  I don't see any other  
platform-specific stuff in there, but then again I don't see any  
elsewhere either.

I've also added a paragraph to the "platform notes" page at http:// 
grass.itc.it/platforms/macgrass.php

Any alteration/addition/clarification suggestions are most welcome.

Here's the paragraph at the moment:

<P>There is one other issue regarding Tcl/Tk under OS X.  The release  
of Tiger (OS 10.4) changed the default configuration of SSH, and it  
has implications for the use of GRASS between hosts on a network  
(i.e. running it on one machine but displaying it on another).  If  
you are interacting with GRASS on a Mac, but actually running it on a  
remote machine that you connect to with SSH, you will need to use the  
"trusted forwarding" mode of SSH in order for the Tcl/Tk generated  
graphics (d.m, the GUI version of the initial mapset selection, plus  
the GUI versions of each GRASS module) to make it through your  
connection.  This can be done using the -Y flag when you start the  
ssh session:
  <tt>ssh -Y remotehost</tt>
  Using the -X flag, or simply turning on X11Forwarding in the SSH  
configuration files, is not enough:  the symptoms in this case are  
that a d.mon window will function fine, but none of the Tcl/Tk  
dialogues will work, failing with an error message complaining either  
about Wish not behaving as expected, or a "Bad Atom". </P>



Cheers,
Scott


> 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
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5