[GRASS-dev] init.sh OSX browser setting

[summary for list]

Two problems with the way GRASS opens help files in OSX:

Init.sh uses a plain ‘open’ as the default for the browser in Mac OS X. This will open help files in whatever application a user has their system set to open html files in. By default this is Safari, but it may not be a browser but a text editor (ie for those web programmers), and for viewing help that’s not helpful.

And, if a user wants a different browser for GRASS (and doesn’t want to change their general system default browser), the normal unix executable way is not right, that is setting, say, /Applications/Firefox.app/Contents/MacOS/Firefox. This opens the application, but if it’s already running it opens another instance - not right on OSX.

The way to handle these problems is to add options to the open command:

open -a /path/to/app/package.app

or:

open -b app.signature

This causes a problem in the scripts, since $GRASS_HTML_BROWSER is quoted everywhere - it tries to execute “open -a /path/to/app/package.app” as the name of a program, not “open”. So, I tried two ways to handle this.

[/summary]

So far I have (in init.sh):

  • alias method - doesn’t work, command not found

alias opengrasshelp=‘open -b com.apple.helpviewer’
GRASS_HTML_BROSWER=opengrasshelp
export GRASS_HTML_BROWSER

Help button in GUI startup and help menu in GUI and in command dialogs:

couldn’t execute “opengrasshelp”: no such file or directory

or if I try to run ‘opengrasshelp’ from the GRASS prompt:

bash: opengrasshelp: command not found

  • script method - an extra etc script html_browser_mac.sh opens the help file in the browser set in GRASS_HTML_BROWSER_MACOSX

This works as a default browser:

GRASS_HTML_BROWSER=“$ETC/html_browser_mac.sh”
GRASS_HTML_BROWSER_MACOSX=“-b com.apple.helpviewer”
export GRASS_HTML_BROWSER_MACOSX
export GRASS_HTML_BROWSER

This also works:

GRASS_HTML_BROWSER_MACOSX=“-b org.mozilla.firefox”

But this opens the default system browser:

GRASS_HTML_BROWSER_MACOSX=“-a /Applications/Firefox.app”

It opens the default browser when used in the Help menu and dialogs, BUT works correctly if typed at the GRASS prompt, like:

$GRASS_HTML_BROWSER_MACOSX /path/to/some/hemp/file.html

I can use the browser signature method, and would prefer that - it’s simpler for the user, and I can put tests in init.sh for common browsers so the user just needs to set GRASS_HTML_BROWSER to a name. But I don’t know the signatures for any other browser than Safari and Firefox, so those would have to be filled in.

I could force the signature method as the only method. Leave browsers that I know as above, but for other browsers the user would have to figure out their signatures.


William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

First Pogril: Why is life like sticking your head in a bucket filled with hyena offal?
Second Pogril: I don’t know. Why IS life like sticking your head in a bucket filled with hyena offal?
First Pogril: I don’t know either. Wretched, isn’t it?

-HitchHiker’s Guide to the Galaxy

William Kyngesburye wrote:

Two problems with the way GRASS opens help files in OSX:

Init.sh uses a plain 'open' as the default for the browser in Mac OS

..

The way to handle these problems is to add options to the open
command:

open -a /path/to/app/package.app
or:
open -b app.signature

This causes a problem in the scripts, since $GRASS_HTML_BROWSER is
quoted everywhere - it tries to execute "open -a /path/to/app/
package.app" as the name of a program, not "open". So, I tried two
ways to handle this.

..

- alias method - doesn't work, command not found

Probably aliases can be exported to child processes?

Did you have any luck with using the built-in help browser?

GRASS_HTML_BROWSER="/System/Library/CoreServices/Help Viewer.app/Contents/MacOS/Help Viewer"

Hamish

On Mar 9, 2007, at 7:04 PM, Hamish wrote:

- alias method - doesn't work, command not found

Probably aliases can be exported to child processes?

If you mean:

alias opengrasshelp="open -b com.apple.helpviewer"
export opengrasshelp

that didn't work either - still command not found.

Did you have any luck with using the built-in help browser?

GRASS_HTML_BROWSER="/System/Library/CoreServices/Help Viewer.app/Contents/MacOS/Help Viewer"

Works great with a signature:

open -b com.apple.helpviewer

You don't want to do it direct as you have it, for the reason already stated (you get multiple instances of an application running).

So, with the alias problem, it needs to be run with the script method.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy

William Kyngesburye wrote:

>> - alias method - doesn't work, command not found
>>
>
> Probably aliases can be exported to child processes?

If you mean:

alias opengrasshelp="open -b com.apple.helpviewer"
export opengrasshelp

that didn't work either - still command not found.

I'm assuming that "can" was a typo; aliases are internal to the shell,
and cannot be inherited by child processes.

--
Glynn Clements <glynn@gclements.plus.com>

William wrote:
> >> - alias method - doesn't work, command not found

H:

> > Probably aliases can be exported to child processes?

W:

> If you mean:
>
> alias opengrasshelp="open -b com.apple.helpviewer"
> export opengrasshelp
>
> that didn't work either - still command not found.

G:

I'm assuming that "can" was a typo; aliases are internal to the shell,
and cannot be inherited by child processes.

yes, I meant to say the opposite.

so

  GRASS_HTML_BROWSER="opengrasshelp.sh"

which contains:

  open -b com.apple.helpviewer "$1"

and is placed somewhere in the PATH.

?
Hamish

On Mar 11, 2007, at 5:08 PM, Hamish wrote:

G:

I'm assuming that "can" was a typo; aliases are internal to the shell,
and cannot be inherited by child processes.

yes, I meant to say the opposite.

he he, being the shell dummy I am, I just blindly followed the wording as typed and tried it anyways...

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy

So, in working out the details for the Mac OS X GRASS_HTML_BROWSER changes needed, I also found that the Apple Help Viewer not only works nicely for viewing GRASS help, but can enable GRASS help to be viewed system-wide. That is, without running GRASS, open Help Viewer (ie from the Finder Help->Mac Help, or from any other application) and GRASS would be in the Library menu.

Another nice feature is that Help Viewer also sees help files in the user's home folder. I've been working on isolating the GRASS binaries from user-installed addons, because in OSX it's not a good idea to alter installed apps directly. I have bin/ and lib/ extras worked out, and have an idea for etc/, but doc/ is troublesome. It's difficult to dynamically access the help files in a user's home folder. With help viewer it's automatic, though still separated from the main GRASS help, but easily accessible.

Also, there is a builtin search feature.

And, for those extrnal html links, the user's browser choice IS used.

The 'open' change must be done, since that's technically a bug, though latent and probably rare.

I'm wondering, since it would make OSX an extra-special case as far as it concerns users customizing which browser to use for help files (it would be by name or app signature, not by executable path), and considering the above features of Help Viewer, if forcing Help Viewer as the only GRASS_HTML_BROWSER for OSX is acceptable? (For the complexity of changes needed, consider a couple lines in init.sh to force it vs. a couple dozen extra lines plus explaining that in the help.)

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy

William Kyngesburye wrote:

I'm wondering, since it would make OSX an extra-special case as far
as it concerns users customizing which browser to use for help files
(it would be by name or app signature, not by executable path), and
considering the above features of Help Viewer, if forcing Help Viewer
as the only GRASS_HTML_BROWSER for OSX is acceptable?

Why not contiunue to allow a custom GRASS_HTML_BROWSER, only if that
isn't set at startup have init.sh set the default to the Help Viewer?

init.sh's default web browser code is already behind a
if [ ! "$GRASS_HTML_BROWSER" ] ; then
   ... moz, konq, etc
fi

so just keep the OSX Help Viewer setup within that check??
Forcing the Help Viewer without a way out isn't so nice.

Is "/Applications" different for non-English language installs?

other business:

Shall [ "`uname -s`" = "Darwin" ] replace:
  [ "$HOSTTYPE" = "macintosh" -o "$HOSTTYPE" = "powermac" \
    -o "$HOSTTYPE" = "powerpc" ]
?

Lorenzo wrote:

$HOSTTYPE var has different output in:
PowerPc 10.2.x --> macintosh
PowerPc 10.3.x --> powermac
PowerPc 10.4.x --> powerpc
MacIntel 10.4.x --> intel-pc

Best option is: uname -s
The output is: Darwin
always in any processor, in any OS X version, I think

(currently init.sh doesn't know about MacIntel)

Package specific stuff for OSX, e.g.:
   if [ "$HOSTTYPE" = "macintosh" ] ; then
      if [ -d "/usr/local/grasslib" ]; then
            GRASS_TCLSH=/usr/local/grasslib/bin/tclsh
      else

needs to be removed from the CVS init.sh. That should be patched back in
by packagers.

Hamish

On Mar 14, 2007, at 11:00 PM, Hamish wrote:

William Kyngesburye wrote:

I'm wondering, since it would make OSX an extra-special case as far
as it concerns users customizing which browser to use for help files
(it would be by name or app signature, not by executable path), and
considering the above features of Help Viewer, if forcing Help Viewer
as the only GRASS_HTML_BROWSER for OSX is acceptable?

Why not contiunue to allow a custom GRASS_HTML_BROWSER, only if that
isn't set at startup have init.sh set the default to the Help Viewer?

init.sh's default web browser code is already behind a
if [ ! "$GRASS_HTML_BROWSER" ] ; then
   ... moz, konq, etc
fi

so just keep the OSX Help Viewer setup within that check??
Forcing the Help Viewer without a way out isn't so nice.

It was just a thought. Though there is the complexity issue - some developers may question the extra tests and mess.

If you want to simplify the patch I sent, you could remove the browser-by-name bits. Then only app signatures would work, and we wouldn't have to add a test for all known browsers and figure out their signatures (let the user figure out signatures).

Is "/Applications" different for non-English language installs?

Hmm... good question. I would guess always /Applications since it's the GUI that localized. And you create Installer packages with fixed paths. Is 'nix localized at that level? ie localized bin/lib/include/... ?

other business:

Shall [ "`uname -s`" = "Darwin" ] replace:
  [ "$HOSTTYPE" = "macintosh" -o "$HOSTTYPE" = "powermac" \
    -o "$HOSTTYPE" = "powerpc" ]
?

Yes. Darwin covers all Mac OS X versions and architectures.

Lorenzo wrote:

$HOSTTYPE var has different output in:
PowerPc 10.2.x --> macintosh
PowerPc 10.3.x --> powermac
PowerPc 10.4.x --> powerpc
MacIntel 10.4.x --> intel-pc

Best option is: uname -s
The output is: Darwin
always in any processor, in any OS X version, I think

(currently init.sh doesn't know about MacIntel)

I'm not sure how Mac Intel comes out as "intel-pc". 'pc' is just wrong already. And this was what I found odd - for me (MacBook) HOSTTYPE produces "powerpc".

So, as above, unsame -s is the way to go.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy

William Kyngesburye wrote:

> Is "/Applications" different for non-English language installs?
>
Hmm... good question. I would guess always /Applications since it's
the GUI that localized. And you create Installer packages with fixed
paths. Is 'nix localized at that level? ie localized bin/lib/
include/... ?

No, but Windows is, e.g. %ProgramFilesDir% is typically
"C:\Program Files" for an English install but "C:\Programme" for a
German install.

--
Glynn Clements <glynn@gclements.plus.com>