[GRASS-dev] [grass-code patches][280] Fix Help button in gis.m raster/vector display conf locks up gis.m

GRASS GIS GRASS GIS developer
1

code patches item #280, was opened at 2007-02-10 19:21
Status: Open
Priority: 3
Submitted By: Māris Nartišs (marisn)
Assigned to: Nobody (None)
Summary: Fix Help button in gis.m raster/vector display conf locks up gis.m
Patch status: None
Patch type: fix
GRASS component: gis.m
GRASS version: CVS HEAD
GRASS CVS checkout date, if applies (YYMMDD): 070210

Initial Comment:
In GRASS 6.2.1 if You press "Help" to get help about raster/vector displaying, it will run g.manual and lock up gis.m till You close browser (konqueror). Not good.
In GRASS 6.3.cvs if You do same, gis.m will remain locked also after closing help browser (konqueror). Only way out after pressing help is to use xkill. Really bad.

This patch changes all "run g.manual foo" in gis.m to "spawn g.manual foo". It works now for me with CVS head (10.02.2007.) and Konqueror. I can open help and continue to use gis.m in same time. If looks OK, somebody commit it, please.

----------------------------------------------------------------------

You can respond by visiting:
http://wald.intevation.org/tracker/?func=detail&atid=205&aid=280&group_id=21

2

Maris,

When I try both "run" and "spawn" procedures for starting g.manual on my Mac
x11 GUI, both work fine without locking up anything. So I can't track why it
may be locking on yours (a few other people reported this issue, but it has
been variable in its persistence AFAICT). However, if I use spawn, it
generates the following message in the terminal every time the module help
button is pressed.

Starting browser <open> for module d.rast...

Other than a bit of clutter, this doesn't cause any other issues (but why do
we have this rather pointless message being sent to stderr?)

There was some recent discussion about help functionality/non-functionality
under windows and I remember something about the menu version of GRASS help
working, while the buttons in the options panels and module dialogs were
problematic sometimes.

This is the code for help in the menu. Maybe it would work better on all
systems (requires "global devnull" to be declared in the relevant
procedure).

exec g.manual -i d.rast > $devnull &

Does this work without lockup for you? Does it work for Windows...anyone?

Michael

On 2/10/07 10:21 AM, "grass-codepatches@wald.intevation.org"
<grass-codepatches@wald.intevation.org> wrote:

code patches item #280, was opened at 2007-02-10 19:21
Status: Open
Priority: 3
Submitted By: M?ris Narti¹s (marisn)
Assigned to: Nobody (None)
Summary: Fix Help button in gis.m raster/vector display conf locks up gis.m
Patch status: None
Patch type: fix
GRASS component: gis.m
GRASS version: CVS HEAD
GRASS CVS checkout date, if applies (YYMMDD): 070210

Initial Comment:
In GRASS 6.2.1 if You press "Help" to get help about raster/vector displaying,
it will run g.manual and lock up gis.m till You close browser (konqueror). Not
good.
In GRASS 6.3.cvs if You do same, gis.m will remain locked also after closing
help browser (konqueror). Only way out after pressing help is to use xkill.
Really bad.

This patch changes all "run g.manual foo" in gis.m to "spawn g.manual foo". It
works now for me with CVS head (10.02.2007.) and Konqueror. I can open help
and continue to use gis.m in same time. If looks OK, somebody commit it,
please.

----------------------------------------------------------------------

You can respond by visiting:
Wald: Exiting with error

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

3

Hello Maris

On Sat, 10 Feb 2007 grass-codepatches@wald.intevation.org wrote:

Initial Comment:
In GRASS 6.2.1 if You press "Help" to get help about raster/vector displaying, it will run g.manual and lock up gis.m till You close browser (konqueror). Not good.
In GRASS 6.3.cvs if You do same, gis.m will remain locked also after closing help browser (konqueror). Only way out after pressing help is to use xkill. Really bad.

This patch changes all "run g.manual foo" in gis.m to "spawn g.manual foo". It works now for me with CVS head (10.02.2007.) and Konqueror. I can open help and continue to use gis.m in same time. If looks OK, somebody commit it, please.

IMHO this is a feature of g.manual, rather than a bug in the GUI. If you run g.manual from the command-line you get the same situation - the command prompt is unusable until the browser is closed again. This has annoyed me many times but I never did anything about it as I considered it a feature rather than a bug---if you run g.manual -m (for man page rather than HTML output) the terminal window is used for reading the help pages so it would be impossible to use it anyway. An historical feature IMHO, but I agree also that it would be desirable to change it.

I think though rather than patching the GUI, a better solution (which will also benefit command-line users) would be to change g.manual so it spawns the help browser and then exits, rather than waiting for the user to close the browser before exiting as at present.

Also (for Maciek) comments:
1. The e-mails (like this one I'm replying to) coming from the request tracker have very long lines in them. Very hard to read in some e-mail clients. Is it possible for the lines to be automatically broken if the user entering the bug doesn't put line breaks in?
2. Is it possible for the e-mails to have grass-dev@grass.itc.it in the To field rather than noreply@wald.intevation.org? What is that for? When I select Reply-to-all it would be easier if the dev list was included in the recipients and I didn't have to edit the Cc field manually.

Paul

4

Paul Kelly wrote:

IMHO this is a feature of g.manual, rather than a bug in the GUI. If
you run g.manual from the command-line you get the same situation -
the command prompt is unusable until the browser is closed again.
This has annoyed me many times but I never did anything about it as I
considered it a feature rather than a bug---if you run g.manual -m
(for man page rather than HTML output) the terminal window is used
for reading the help pages so it would be impossible to use it
anyway. An historical feature IMHO, but I agree also that it would be
desirable to change it.

I think though rather than patching the GUI, a better solution (which
will also benefit command-line users) would be to change g.manual so
it spawns the help browser and then exits, rather than waiting for
the user to close the browser before exiting as at present.

I had applied such a g.manual& patch in the past, but it was reverted
after we discovered that some people were using text based browsers
(lynx, links) to view the help pages, and this caused problems for them.

that discussion:
  http://thread.gmane.org/gmane.comp.gis.grass.devel/6702

FWIW, In my ~/.grass.bashrc I export GRASS_HTML_BROWSER=dillo, which is
Very Fast (and flags html bugs) but noisy to stderr. I guess folks using
a text based web browser for the help pages could use man instead of
lynx.

Also, I never managed to get the command line options right so firefox
would open a new window in the current workspace; if used for GRASS help
it opens the page in the current tab a an existing firefox in another
workspace. I've the same problem with Googlizer.
  mozilla -remote "openurl(http://www.mozilla.org)"

  http://www.linux.org.uk/~telsa/BitsAndPieces/googlizer.html
   (nice little tool- highlight a word and click on the "G" icon
    on the taskbar to do a search for that word. useless triva:
    the author is Alan Cox's SO)

Also, for me, "man $module" works the same as "g.manual -m $module"
but with less keystrokes.

Hamish

5

Michael Barton wrote:

Starting browser <open> for module d.rast...

lib/init/init.sh sets this:

  elif [ "$HOSTTYPE" = "macintosh" -o "$HOSTTYPE" = "powermac" -o "$HOSTTYPE" = "powerpc" ] ; then
      GRASS_HTML_BROWSER=open

As for MacOSX you can do "open URL" from the command line to launch safari.

Apparently that forks itself into a background process, but that behavior
is specific to OSX's "open" command. If GRASS_HTML_BROWSER is set to a
regular program name, it probably won't background itself.

Hamish

6

Right. But why is a message generated to tell me that I am starting a browser for module d.rast... This is what I intended to do, and a message to this effect sent to stderr seems redundant. I can see getting a message "Unable to open browser <open> for module d.rast...", but I don't see why one is necessary to tell the user that the program is indeed doing what it is supposed to do. (grumble grumble grumble). This is a message that I don't remember seeing before.

Michael

On Feb 11, 2007, at 9:32 PM, Hamish wrote:

Michael Barton wrote:

Starting browser <open> for module d.rast...

lib/init/init.sh sets this:

  elif [ "$HOSTTYPE" = "macintosh" -o "$HOSTTYPE" = "powermac" -o "$HOSTTYPE" = "powerpc" ] ; then
      GRASS_HTML_BROWSER=open

As for MacOSX you can do "open URL" from the command line to launch safari.

Apparently that forks itself into a background process, but that behavior
is specific to OSX's "open" command. If GRASS_HTML_BROWSER is set to a
regular program name, it probably won't background itself.

Hamish

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

7

H:

>> Starting browser <open> for module d.rast...
>
> lib/init/init.sh sets this:
>
> elif [ "$HOSTTYPE" = "macintosh" -o "$HOSTTYPE" = "powermac" -o
> "$HOSTTYPE" = "powerpc" ] ; then
> GRASS_HTML_BROWSER=open
>
>
> As for MacOSX you can do "open URL" from the command line to launch
> safari.
>
> Apparently that forks itself into a background process, but that
> behavior is specific to OSX's "open" command. If GRASS_HTML_BROWSER
> is set to a regular program name, it probably won't background
> itself.

sorry, the above is wrong. There is an override in scripts/g.manual:

#hack for MacOSX:
if [ "$HOSTTYPE" = "macintosh" ] ; then
    BROWSERNAME="default Macintosh web browser"

Michael Barton wrote:

Right. But why is a message generated to tell me that I am starting a
browser for module d.rast... This is what I intended to do, and a
message to this effect sent to stderr seems redundant. I can see
getting a message "Unable to open browser <open> for module
d.rast...", but I don't see why one is necessary to tell the user
that the program is indeed doing what it is supposed to do. (grumble
grumble grumble). This is a message that I don't remember seeing
before.

That message has been there since the first version. I guess it is like
websites opening a new browser window instead of exiting the current
page when you click on an external link (!@$@#%&*). Some sort of "not
my fault if this doesn't work" absolving legaleese I guess. Also the
new brower may take several seconds to load and the user may become
impatient and open it twice, esp. if it returns to the prompt.

options:
1) send the message to stderr with `echo "" 1>&2`, where all good
shell script status messages should go.
2) "g.manual --quiet" makes it go away
2) restrict it to when "g.manual --verbose" is called
3) remove it (problem if GRASS_HTML_BROWSER is bad?)
4) do nothing

#1 and #2 are now done in 6.3-CVS.

Hamish

8

g.manual --quiet is a good solution. Thanks.

Michael
On Feb 11, 2007, at 11:03 PM, Hamish wrote:

H:

Starting browser <open> for module d.rast...

lib/init/init.sh sets this:

  elif [ "$HOSTTYPE" = "macintosh" -o "$HOSTTYPE" = "powermac" -o
"$HOSTTYPE" = "powerpc" ] ; then
      GRASS_HTML_BROWSER=open

As for MacOSX you can do "open URL" from the command line to launch
safari.

Apparently that forks itself into a background process, but that
behavior is specific to OSX's "open" command. If GRASS_HTML_BROWSER
is set to a regular program name, it probably won't background
itself.

sorry, the above is wrong. There is an override in scripts/g.manual:

#hack for MacOSX:
if [ "$HOSTTYPE" = "macintosh" ] ; then
    BROWSERNAME="default Macintosh web browser"

Michael Barton wrote:

Right. But why is a message generated to tell me that I am starting a
browser for module d.rast... This is what I intended to do, and a
message to this effect sent to stderr seems redundant. I can see
getting a message "Unable to open browser <open> for module
d.rast...", but I don't see why one is necessary to tell the user
that the program is indeed doing what it is supposed to do. (grumble
grumble grumble). This is a message that I don't remember seeing
before.

That message has been there since the first version. I guess it is like
websites opening a new browser window instead of exiting the current
page when you click on an external link (!@$@#%&*). Some sort of "not
my fault if this doesn't work" absolving legaleese I guess. Also the
new brower may take several seconds to load and the user may become
impatient and open it twice, esp. if it returns to the prompt.

options:
1) send the message to stderr with `echo "" 1>&2`, where all good
shell script status messages should go.
2) "g.manual --quiet" makes it go away
2) restrict it to when "g.manual --verbose" is called
3) remove it (problem if GRASS_HTML_BROWSER is bad?)
4) do nothing

#1 and #2 are now done in 6.3-CVS.

Hamish

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

9

Another issue.. gis.m loaded from init.sh ignores ~/.grass.bashrc.

e.g. my ~/.grass.bashrc has:
export GRASS_HTML_BROWSER=dillo

If I start GRASS in -gui mode the [Help] button from the gis.m menus
ignores my $GRASS_HTML_BROWSER setting and uses Mozilla.

If I start gis.m from an already running GRASS prompt, [Help] loads
dillo.

Should:
- the terminal session somehow start gis.m instead of init.sh
- gis.m "source" .grass.bashrc (& co.) if it exists
- in init.sh move source .grass.bashrc (& co.) before the gui startup
- or we drop .rc support for GUI GRASS :frowning:

Polluting ~/.bashrc with a lot of GRASS stuff is a pain.

Another example: in .grass.bashrc I renice GRASS to a low priority (+15)
so during long processing jobs I can work on other things without much
slowdown.

Hamish

10

Hamish wrote:

Another issue.. gis.m loaded from init.sh ignores ~/.grass.bashrc.

e.g. my ~/.grass.bashrc has:
export GRASS_HTML_BROWSER=dillo

If I start GRASS in -gui mode the [Help] button from the gis.m menus
ignores my $GRASS_HTML_BROWSER setting and uses Mozilla.

If I start gis.m from an already running GRASS prompt, [Help] loads
dillo.

Should:
- the terminal session somehow start gis.m instead of init.sh

Possible; just append "gis.m &" to the temporary .bashrc file which it
creates.

- gis.m "source" .grass.bashrc (& co.) if it exists

You can't "source" a bash script from Tcl, and "exec"ing it won't
affect gis.m's environment.

- in init.sh move source .grass.bashrc (& co.) before the gui startup

That will only work for .grass.bashrc, not for .grass.cshrc (init.sh
is a Bourne-shell script, so it can't "source" a csh script).

- or we drop .rc support for GUI GRASS :frowning:

I'd suggest having a distinct "config" script for GRASS, which
contains Bourne-shell commands (mainly environment settings) and which
is sourced at the beginning of Init.sh.

~/.grass.bashrc (and cshrc) are meant for the session shell; nothing
in them can affect Init.sh itself.

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

11

Hi all,

I tested recent g.manual with gis.m.
Starting help now launches my browser (Konqueror) and locks up gis.m.
After I close browser, gis.m is unlocked - usable. Now works like in
6.2 time. Still IMHO this sucks.

As I understood, we may not be able to change way g.manual works as it
will break backward compatability (probably new switch -spawn could do
trick?). If nothing more can be done for g.manual, then we should
atleast make gis.m usable by changing all "run g.manual" calls to
"spawn g.manual".

Just my 0.02c,
Maris.

2007/2/12, Michael Barton <c.michael.barton@gmail.com>:

g.manual --quiet is a good solution. Thanks.

Michael
On Feb 11, 2007, at 11:03 PM, Hamish wrote: