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

[Kirk R. Wythers]

On Mar 14, 2006, at 10:05 AM, Scott Mitchell wrote:

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

You are most welcome. I was more than a little embarrassed when I  
realized what was going on.

>
>> 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 "borrowed" some of your below language and did the addition to Tips  
and Tricks.

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

Looks good. Thanks Scott.


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