[GRASS-dev] Re: Fix Help button in gis.m raster/vector display conf locks up gis.m

GRASS GIS GRASS GIS developer
1

Maris,

I was still waiting on wingrass to decide how best to deal with g.manual
running modally on some systems (i.e., on your Linux system but not on Mac
OS X).

On my Mac, spawn works but generates an annoying and useless message to
console each time. It doesn't matter if I add the --q switch or not.

Oddly, in your case it only generates the message if you DO use the --q
switch. This makes me wonder what the --q switch is doing in g.manual since
it appears to be creating verbose output rather than preventing it.

If I declare the global variable devnulls at the beginning of the options
panel procedure, I can use the form

spawn g.manual module > $devnulls &

OR

exec g.manual module > $devnulls &

Both work fine on my Mac and do NOT generate the annoying message.

How do these work on your system?

Moritz -- Does this work with Windows???

Michael

On 2/16/07 10:02 AM, "Maris Nartiss" <maris.gis@gmail.com> wrote:

Hi,

probablhy You did not changed anything, but I was ahcking around and
forgot about it.
Newest results (GRASS 6.3 a week(?) old CVS (I have not updated for some
time)):

Plain version (no modification):
* gis.m raster help button locks up gis.m. Have to xkill it;
* gis.m Help-> GRASS Help works fine - no lockups etc.
* comandline g.manual - comandline remains locked till I exit help browser.

run g.manual --q d.rast:
* gis.m raster help locks up gis.m till I close my help browser. After
closing it, gis.m is useable

spawn g.manual --q d.rast:
* after launching Help browser, I can use gis.m w/o problems without
requirement to close help (yapiiiii).

spawn g.manual d.rast:
* Same as without --q (works), except now is a message printed to
console about launching browser.

IMHO best is "spawn g.manual --q module", as it prints no message and
allows to use gis.m in paralel to help page browsing.

Should I create new patch for this?

WBR,
Maris.

2007/2/14, Michael Barton <michael.barton@asu.edu>:

Maris,

I haven't changed anything, so it will work the same.

Since it doesn't lock up on my Mac, it is hard to test alternative
approaches. Maybe you can help.

Instead of run, try spawn and the g.manual --quiet
Also, try the execute statement used in the menu version of help.

Which of these work better, worse, same?

I'd also like to find a solution that also works in Windows. Currently, it
doesn't work at all or crashes in winGRASS.

Michael

On 2/13/07 1:43 AM, "Maris Nartiss" <maris.gis@gmail.com> wrote:

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:

__________________________________________
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

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

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

2

Hi Michael,

I'm really sorry for my english. Reading Linux realted RTFMs may not
be best way how to learn language.

I was saying, that --q gives NO output to console, without --q it
print that unneccessary message about "Starting browser...".

"exec g.manual d.rast > /dev/null &" will print same message "Starting
browser <konqueror> for module d.rast" to console. Where is $devnulls
defined? By simply adding "global devnulls" I had no success, thus I
used plain /dev/null for testing.

"spawn g.manual d.rast > /dev/null &" fails completly with error
message in console - "Sorry, <&> is not a valid parameter" (translated
from Latvian).

I wote for using "spawn g.manual --q module" as it gives best results.

Maris.

PS. Michael, have You updated Your g.manual module after 12. feb.
2007? I see, that --q support was introduced after 12 feb.

2007/2/16, Michael Barton <michael.barton@asu.edu>:

Maris,

I was still waiting on wingrass to decide how best to deal with g.manual
running modally on some systems (i.e., on your Linux system but not on Mac
OS X).

On my Mac, spawn works but generates an annoying and useless message to
console each time. It doesn't matter if I add the --q switch or not.

Oddly, in your case it only generates the message if you DO use the --q
switch. This makes me wonder what the --q switch is doing in g.manual since
it appears to be creating verbose output rather than preventing it.

If I declare the global variable devnulls at the beginning of the options
panel procedure, I can use the form

spawn g.manual module > $devnulls &

OR

exec g.manual module > $devnulls &

Both work fine on my Mac and do NOT generate the annoying message.

How do these work on your system?

Moritz -- Does this work with Windows???

Michael

On 2/16/07 10:02 AM, "Maris Nartiss" <maris.gis@gmail.com> wrote:

> Hi,
>
> probablhy You did not changed anything, but I was ahcking around and
> forgot about it.
> Newest results (GRASS 6.3 a week(?) old CVS (I have not updated for some
> time)):
>
> Plain version (no modification):
> * gis.m raster help button locks up gis.m. Have to xkill it;
> * gis.m Help-> GRASS Help works fine - no lockups etc.
> * comandline g.manual - comandline remains locked till I exit help
browser.
>
> run g.manual --q d.rast:
> * gis.m raster help locks up gis.m till I close my help browser. After
> closing it, gis.m is useable
>
> spawn g.manual --q d.rast:
> * after launching Help browser, I can use gis.m w/o problems without
> requirement to close help (yapiiiii).
>
> spawn g.manual d.rast:
> * Same as without --q (works), except now is a message printed to
> console about launching browser.
>
> IMHO best is "spawn g.manual --q module", as it prints no message and
> allows to use gis.m in paralel to help page browsing.
>
> Should I create new patch for this?
>
> WBR,
> Maris.
>
> 2007/2/14, Michael Barton <michael.barton@asu.edu>:
>> Maris,
>>
>> I haven't changed anything, so it will work the same.
>>
>> Since it doesn't lock up on my Mac, it is hard to test alternative
>> approaches. Maybe you can help.
>>
>> Instead of run, try spawn and the g.manual --quiet
>> Also, try the execute statement used in the menu version of help.
>>
>> Which of these work better, worse, same?
>>
>> I'd also like to find a solution that also works in Windows. Currently,
it
>> doesn't work at all or crashes in winGRASS.
>>
>> Michael
>>
>> On 2/13/07 1:43 AM, "Maris Nartiss" <maris.gis@gmail.com> wrote:
>>
>>> 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:
>>>>
>>>
>>
>> __________________________________________
>> 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
>>

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

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