[GRASS-dev] Re: New xterm wrapper not working on Mac build

[William Kyngesburye]

Hmm, when I saw the xterm wrapper thread, I kinda wondered how it  
might affect GRASS running from a Mac Terminal.  I'm not sure about  
the details on how the wrapper is used, but when an xterm is needed,  
would a Mac Terminal work?

One thing I added to my custom GRASS.app startup is a  
GRASS_OS_STARTUP env var.  I set it to "Mac.app" and it was initially  
used when I added to the existing grass6 startup shell, but now I use  
a completely custom grass startup shell because I couldn't figure out  
how to pass args from the open command.  I left GRASS_OS_STARTUP in  
the startup, so maybe grass-xterm-wrapper can use this to set  
GRASS_XTERM to open a Terminal instead of an xterm?

It would be kinda tricky - exec'ing a Terminal directly would  
actually run Terminal.app again instead of creating a new window in  
an already-running Terminal (not good, most Mac apps are only meant  
to be run once), instead it would need to be run from 'open' (this is  
how I start GRASS in my python startup).  But this will only work to  
run a script from a file, not open an empty Terminal window, unless  
there is no window currently open.

For running a script in a new window (open doesn't need to run from  
exec, and returns immediately without waiting for the script to run -  
it's just 'opening' a file in an application):

/usr/bin/open -a Terminal some_script_file.sh

Without a script file, it just opens the Terminal, and if there is no  
window open, it will open a new one (what we want), but if there is  
already one open (there is because GRASS was started in one) it will  
just activate the frontmost window.

I thought about doing an inline AppleScript, but the Terminal's  
scriptability is surprisingly limited - there is no way to open a new  
window.  It could be done with the System Events scripting to  
manually choose a menu item, but that's messy and requires a user to  
activate Universal Access.


If the xterm usage needs specific xterm options, then a Terminal  
probably won't work, since it doesn't have startup options except for  
running a script.  Which makes me wonder - if an xterm is explicitly  
needed, that makes it difficult to separate the GUI from X11 if a  
user wanted to use Tcl/Tk Aqua (or a native Windows TclTk, if that  
option works).


Or, if the GUI is running in an X11 Tcl/Tk, you probably want xterms  
for a consistent look.


For running from the CLI, I did a search and the only place an xterm  
is used is r[3].mapcalculator, to run in 'expert' mode (and without  
grass-run.sh).  That doesn't sound right - won't it be missing the  
GRASS running environment?  Why should it run in a separate window in  
the first place?


Do you have a specific example of grass-xterm-wrapper use in the CLI  
that fails?


On Sep 4, 2006, at 2:08 PM, Michael Barton wrote:

> I just discovered that the xterm wrapper script does not work for  
> Willaim Kyngesburye’s framework build binaries for the Mac, and  
> won’t work for Lorenzo’s binaries either in some circumstances.
>
> The issue is that the Mac BASH terminal is used as the GRASS  
> terminal rather than an xterm. The Mac terminal is much easier to  
> use. But when grass-xterm-wrapper.sh is run from the BASH terminal,  
> it doesn’t realize that x is running and returns a command not  
> found error. This is not a problem when an xterm is launched from  
> TclTk, which IS running in X-windows.
>
> Solutions?
>
> Michael
>
-----
William Kyngesburye <kyngchaos at kyngchaos.com>
http://www.kyngchaos.com/

"We are at war with them. Neither in hatred nor revenge and with no  
particular pleasure I shall kill every ___ I can until the war is  
over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people  
of the allied nations devoted an entire year exclusively to hating  
the ____ it wouldn't kill one ___ nor shorten the war one day."

<Ha, ha> "And it might give 'em all stomach ulcers."

- Tarzan, on war