Here's another command using the contents of manual for messing up the GUI -
r.in.ascii. This one even inputs some nonsense default parameters into the
GUI, not only suggests them:
'mult=1.0 'mult=1.0 or read from header'
'nv=* or read from header'
Of course running the module with such defaults leads to a failure.
Maciek
P.S.
I'm renaming the report to "corrupted defaults and comments in GUI".
-------------------------------------------- Managed by Request Tracker
Maciek,
Again, the dialogs that pop up when you run a GRASS command are NOT a part
of the dm/GIS Manager. They are generated from the C-code of the module (or
the script code for shell scripts). If you want to report a bug or wish with
one of these dialogs and get it fixed, don't report it as a dm bug. I agree
that some of these could use better descriptions of options. Suggested text
improvements would help those who maintain the relevant modules.
In this case, you need to report this as a bug for v.in.ascii--not d.m.
Michael
On 1/20/06 8:41 AM, "Maciek Sieczka via RT" <grass-bugs@intevation.de>
wrote:
Here's another command using the contents of manual for messing up the GUI -
r.in.ascii. This one even inputs some nonsense default parameters into the
GUI, not only suggests them:'mult=1.0 'mult=1.0 or read from header'
'nv=* or read from header'Of course running the module with such defaults leads to a failure.
Maciek
P.S.
I'm renaming the report to "corrupted defaults and comments in GUI".-------------------------------------------- Managed by Request Tracker
___________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287
WWW - http://www.public.asu.edu/~cmbarton
Phone: 480-965-6262
Fax: 480-965-7671
On sob, 2006-01-21 at 12:11 -0700, Michael Barton wrote:
Maciek,
Again, the dialogs that pop up when you run a GRASS command are NOT a part
of the dm/GIS Manager. They are generated from the C-code of the module (or
the script code for shell scripts). If you want to report a bug or wish with
one of these dialogs and get it fixed, don't report it as a dm bug. I agree
that some of these could use better descriptions of options. Suggested text
improvements would help those who maintain the relevant modules.In this case, you need to report this as a bug for v.in.ascii--not d.m.
I have reanmed it yestarday, before you replied. Raed Yestarday I wrote:
I'm renaming the report to "corrupted defaults and comments in GUI".
Michael
On 1/20/06 8:41 AM, "Maciek Sieczka via RT" <grass-bugs@intevation.de>
wrote:> Here's another command using the contents of manual for messing up the GUI -
> r.in.ascii. This one even inputs some nonsense default parameters into the
> GUI, not only suggests them:
>
> 'mult=1.0 'mult=1.0 or read from header'
> 'nv=* or read from header'
>
> Of course running the module with such defaults leads to a failure.
>
> Maciek
>
> P.S.
> I'm renaming the report to "corrupted defaults and comments in GUI".
>
> -------------------------------------------- Managed by Request Tracker
>___________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287WWW - http://www.public.asu.edu/~cmbarton
Phone: 480-965-6262
Fax: 480-965-7671_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
--------------------
Szukasz do¶wiadczonej firmy poligraficznej? Zale¿y Ci na terminowo¶ci i atrakcyjnych cenach?
Zapraszamy do nas!
http://www.foldruk.pl/
On sob, 2006-01-21 at 12:11 -0700, Michael Barton wrote:
Maciek,
Again, the dialogs that pop up when you run a GRASS command are NOT a part
of the dm/GIS Manager. They are generated from the C-code of the module (or
the script code for shell scripts). If you want to report a bug or wish with
one of these dialogs and get it fixed, don't report it as a dm bug. I agree
that some of these could use better descriptions of options. Suggested text
improvements would help those who maintain the relevant modules.In this case, you need to report this as a bug for v.in.ascii--not d.m.
Michael,
Sorry, accidentaly I sent the reply to soon. I wanted to write:
I renamed the bug to "corrupted defaults and comments in GUI" yesterday,
before you replied. This bug doesn't seem to be limited to v.in.ascii.
It is a problem in the general GUI dialogs design. This could happen
with any module depending on how it's manual is formatted.
Maciek
--------------------
Szukasz do¶wiadczonej firmy poligraficznej? Zale¿y Ci na terminowo¶ci i atrakcyjnych cenach?
Zapraszamy do nas!
http://www.foldruk.pl/
Actually, I think it is the other way around (check with Markus on this).
The manual page is built out of the module descriptions in the C-code. If
I've got this right, then the updates need to go to the code (I think it's
main.h or something like that). This would improve both the module GUI and
documentation.
Michael
On 1/21/06 12:42 PM, "Maciek Sieczka" <werchowyna@epf.pl> wrote:
On sob, 2006-01-21 at 12:11 -0700, Michael Barton wrote:
Maciek,
Again, the dialogs that pop up when you run a GRASS command are NOT a part
of the dm/GIS Manager. They are generated from the C-code of the module (or
the script code for shell scripts). If you want to report a bug or wish with
one of these dialogs and get it fixed, don't report it as a dm bug. I agree
that some of these could use better descriptions of options. Suggested text
improvements would help those who maintain the relevant modules.In this case, you need to report this as a bug for v.in.ascii--not d.m.
Michael,
Sorry, accidentaly I sent the reply to soon. I wanted to write:
I renamed the bug to "corrupted defaults and comments in GUI" yesterday,
before you replied. This bug doesn't seem to be limited to v.in.ascii.
It is a problem in the general GUI dialogs design. This could happen
with any module depending on how it's manual is formatted.Maciek
--------------------
Szukasz do¶wiadczonej firmy poligraficznej? Zale¿y Ci na terminowo¶ci i
atrakcyjnych cenach?
Zapraszamy do nas!
http://www.foldruk.pl/
___________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287
WWW - http://www.public.asu.edu/~cmbarton
Phone: 480-965-6262
Fax: 480-965-7671
The manual page is built out of the module descriptions in the
C-code. If I've got this right, then the updates need to go to the
code (I think it's main.h or something like that). This would improve
both the module GUI and documentation.
main.c, yes. help page header is created with "g.module
--html-description"
from the GRASS prompt. Code to make the Tcl/Tk window is created with
"g.module --tcltk". Try it.
As for v.in.ascii coulmns=, I don't think the problem is in the
description, that seems clear enough to me. I'm all for making things
easier on the users but figuring out you have to remove the quotes from
around an example is pretty basic. (yes, I've made that same mistake)
If there is a problem in the GUI it is from the GUI assuming too much
from the description, or descriptive text existing in the options
section.
What I am trying to say is don't change the C code to mask mistakes in
the GUI.. fix the GUI.
Of course if a description _is_ really misleading or confusing there's
grounds to change it.
Hamish
Right. It just that the GUI that is being discussed is the one that is
automatically generated from text in main.c, not from anything in the d.m.
My version of r.in.ascii (9 January 2006) does not match what Maciek is
describing. However, there are some 'hints' put into the fields that should
probably be in the field descriptions.
I just looked at main.c for r.in.ascii on the web cvs. Here is the relevant
code:
parm.mult = G_define_option();
parm.mult->key = "mult";
parm.mult->type = TYPE_DOUBLE;
parm.mult->answer = "1.0 or read from header";
parm.mult->required = NO;
parm.mult->description = _("Multiplier for ascii data") ;
parm.nv = G_define_option();
parm.nv->key = "nv";
parm.nv->type = TYPE_STRING;
parm.nv->required = NO;
parm.nv->multiple = NO;
parm.nv->answer = "* or read from header";
parm.nv->description = _("String representing NULL value data cell");
The lines " parm.nv->answer = ..." put a string into the field as a default.
It looks like a 'hint' was put here to help the user decide what to put in
the field. However, this is supposed to be a default value rather than a
hint.
What I take this to mean is that for nv, you can put in a string ("*" being
a default string to use) to indicate null values or you can leave this blank
and GRASS will attempt to find a null value string specified in the file
header.
Given that GRASS could also look for a field value multiplier in the file
header, a better way to do this might be to make a flag (-h perhaps) that
tell GRASS to look in the file header for null value and multiplier
specifications. Otherwise, look in the r.in.ascii arguments nv and mult.
Then "*" and "1.0" could be left in as default values that actually work,
without the added "or read from header". There is probably a need for more
room for field entry description as this is done in a number of other places
too. For example, something like 1-100 is often put into fields to mean that
you need to enter a value between 1 and 100, and to limit acceptable values
to the 1-100 range.
Michael
On 1/21/06 9:56 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
The manual page is built out of the module descriptions in the
C-code. If I've got this right, then the updates need to go to the
code (I think it's main.h or something like that). This would improve
both the module GUI and documentation.main.c, yes. help page header is created with "g.module
--html-description"
from the GRASS prompt. Code to make the Tcl/Tk window is created with
"g.module --tcltk". Try it.As for v.in.ascii coulmns=, I don't think the problem is in the
description, that seems clear enough to me. I'm all for making things
easier on the users but figuring out you have to remove the quotes from
around an example is pretty basic. (yes, I've made that same mistake)
If there is a problem in the GUI it is from the GUI assuming too much
from the description, or descriptive text existing in the options
section.What I am trying to say is don't change the C code to mask mistakes in
the GUI.. fix the GUI.Of course if a description _is_ really misleading or confusing there's
grounds to change it.Hamish
___________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287
WWW - http://www.public.asu.edu/~cmbarton
Phone: 480-965-6262
Fax: 480-965-7671