menuform.py uses the xml text generated by “ —interface-description” to create the autogenerated dialogs. This dates to 2001.
I was just reminded in a recent post to the grass developer list that there is a richer interface description output called by “ --tcltk”. This has been developed over the past year or so. I give an example below (part of the output from “d.vect —tcltk”). We might want to consider switching the autogenerated panels to be created by the —tcltk code.
Besides being a richer set of descriptions (includes prompt for notebook tabs and color picking dialogs), it looks easier to parse than the —interface description xml. It would also mean that we would not need sax.
menuform.py uses the xml text generated by “<command>
—interface-description” to create the autogenerated dialogs. This dates
to 2001.
I was just reminded in a recent post to the grass developer list that
there is a richer interface description output called by “<command>
--tcltk”. This has been developed over the past year or so. I give an
example below (part of the output from “d.vect —tcltk”). We might want
to consider switching the autogenerated panels to be created by the
—tcltk code.
Besides being a richer set of descriptions (includes prompt for notebook
tabs and color picking dialogs), it looks easier to parse than the
—interface description xml. It would also mean that we would not need sax.
You are having problems parsing XML? Have you looked at the
xml.dom.minidom package? It provides a clean and easy DOM parser. If you
want I can write the parser (: (yay something I can do for the GUI).
Another, perhaps easier, alternative would be to add a --python flag
which would make the parser spew python code.
Mmmmm... I'd rather fix the XML generator in parser.c and Jan's DTD to
take care of guisection. I'm on it.
Daniel.
On 3/22/07, Michael Barton <michael.barton@asu.edu> wrote:
menuform.py uses the xml text generated by "<command>
—interface-description" to create the autogenerated dialogs. This dates to
2001.
I was just reminded in a recent post to the grass developer list that there
is a richer interface description output called by "<command> --tcltk". This
has been developed over the past year or so. I give an example below (part
of the output from "d.vect —tcltk"). We might want to consider switching the
autogenerated panels to be created by the —tcltk code.
Besides being a richer set of descriptions (includes prompt for notebook
tabs and color picking dialogs), it looks easier to parse than the
—interface description xml. It would also mean that we would not need sax.
GRASS 6.3.cvs (spearfish60_test):~ > d.vect --tcltk
begin_dialog {d.vect} {
label {}
desc {Displays GRASS vector data in the active frame on the graphics
monitor.}
key {display}
}
add_flag 1 {
name {v}
desc {Run verbosely}
answer 0
label {}
guisection {}
}
add_flag 2 {
name {a}
desc {Get colors from map table column (of form RRR:GGG:BBB)}
answer 0
label {}
guisection {Colors}
}
add_flag 3 {
name {c}
desc {Random colors according to category number (or layer number if
'layer=-1' is given)}
answer 0
label {}
guisection {Colors}
}
add_flag 4 {
name {i}
desc {Use values from 'cats' option as line ID}
answer 0
label {}
guisection {Query}
}
add_flag 5 {
name {x}
desc {Don't add to list of vectors and commands in monitor (it won't be
drawn if the monitor is refreshed)}
answer 0
label {}
guisection {}
}
add_option 6 {
name {map}
type {name}
multi 0
desc {Name of input vector map}
required 1
options {}
answer {}
prompt {old,vector,vector}
label {}
guisection {}
}
add_option 7 {
name {type}
type {string}
multi 1
desc {Feature type(s)}
required 0
options {point,line,boundary,centroid,area,face}
answer {point,line,boundary,centroid,area,face}
prompt {}
label {Type}
guisection {}
}
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
I've added guisection output to the XML generation in parser.c. While
looking for other weirdnesses in the different output formats, I came
across ->descriptions. So far, only --script makes use of them, and
I've grepped through vector/ raster/ and scripts/ and found that only
the following use it:
v.category
v.clean
v.drape
v.to.db
r.colors
For completeness sake, I would add ->descriptions handling in all of
HTML (where I think it is the most useful), tcltk and xml output, but
I wonder... Is there any chance of ->descriptions being more used?
Maybe add something in SUBMITTING and SUBMITTING_SCRIPTS?
Thoughts?
Daniel.
On 3/22/07, Michael Barton <michael.barton@asu.edu> wrote:
If you go that route, compare the results of --interface-description and
--tcltk to see what else is missing from the xml generator.
I had rendering working great and now it is not. It is not compsiting
properly. I might do a restart to see if it is random. But please check if
you could.
Cheers
Michael
On 3/21/07 11:19 PM, "Daniel Calvelo" <dca.gis@gmail.com> wrote:
> Mmmmm... I'd rather fix the XML generator in parser.c and Jan's DTD to
> take care of guisection. I'm on it.
>
> Daniel.
>
> On 3/22/07, Michael Barton <michael.barton@asu.edu> wrote:
>>
>> menuform.py uses the xml text generated by "<command>
>> ‹interface-description" to create the autogenerated dialogs. This dates to
>> 2001.
>>
>> I was just reminded in a recent post to the grass developer list that there
>> is a richer interface description output called by "<command> --tcltk". This
>> has been developed over the past year or so. I give an example below (part
>> of the output from "d.vect ‹tcltk"). We might want to consider switching the
>> autogenerated panels to be created by the ‹tcltk code.
>>
>> Besides being a richer set of descriptions (includes prompt for notebook
>> tabs and color picking dialogs), it looks easier to parse than the
>> ‹interface description xml. It would also mean that we would not need sax.
>>
>> Michael
>>
>> ======= --tcltk style interface description ==========
>>
>> GRASS 6.3.cvs (spearfish60_test):~ > d.vect --tcltk
>> begin_dialog {d.vect} {
>> label {}
>> desc {Displays GRASS vector data in the active frame on the graphics
>> monitor.}
>> key {display}
>> }
>> add_flag 1 {
>> name {v}
>> desc {Run verbosely}
>> answer 0
>> label {}
>> guisection {}
>> }
>> add_flag 2 {
>> name {a}
>> desc {Get colors from map table column (of form RRR:GGG:BBB)}
>> answer 0
>> label {}
>> guisection {Colors}
>> }
>> add_flag 3 {
>> name {c}
>> desc {Random colors according to category number (or layer number if
>> 'layer=-1' is given)}
>> answer 0
>> label {}
>> guisection {Colors}
>> }
>> add_flag 4 {
>> name {i}
>> desc {Use values from 'cats' option as line ID}
>> answer 0
>> label {}
>> guisection {Query}
>> }
>> add_flag 5 {
>> name {x}
>> desc {Don't add to list of vectors and commands in monitor (it won't be
>> drawn if the monitor is refreshed)}
>> answer 0
>> label {}
>> guisection {}
>> }
>> add_option 6 {
>> name {map}
>> type {name}
>> multi 0
>> desc {Name of input vector map}
>> required 1
>> options {}
>> answer {}
>> prompt {old,vector,vector}
>> label {}
>> guisection {}
>> }
>> add_option 7 {
>> name {type}
>> type {string}
>> multi 1
>> desc {Feature type(s)}
>> required 0
>> options {point,line,boundary,centroid,area,face}
>> answer {point,line,boundary,centroid,area,face}
>> prompt {}
>> label {Type}
>> guisection {}
>> }
>>
>> __________________________________________
>> 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
>>
>> _______________________________________________
>> grassgui mailing list
>> grassgui@grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grassgui
>>
>
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
I've added guisection output to the XML generation in parser.c. While
(thanks)
looking for other weirdnesses in the different output formats, I came
across ->descriptions. So far, only --script makes use of them, and
I've grepped through vector/ raster/ and scripts/ and found that only
the following use it:
v.category
v.clean
v.drape
v.to.db
r.colors
For completeness sake, I would add ->descriptions handling in all of
HTML (where I think it is the most useful), tcltk and xml output, but
that would be nice. The GUI programmer can decide what to do with it,
but the parser should make it available to them.
I wonder... Is there any chance of ->descriptions being more used?
Maybe add something in SUBMITTING and SUBMITTING_SCRIPTS?
Hi,
I agree, that we should improve --interface-description rather than
get rid of it. It can be used in the future for *any* other interface.
Wolf, you can script some class, which would produce wxpython codde on
it. This way, the input forms could be bound into any other GUI, also
for non-grass developers, who want to use GRASS modules in their
program
thanks a lot
jachym
2007/3/22, Wolf Bergenheim <wolf+grass@bergenheim.net>:
On 22.03.2007 07:31, Michael Barton wrote:
> menuform.py uses the xml text generated by "<command>
> —interface-description" to create the autogenerated dialogs. This dates
> to 2001.
>
> I was just reminded in a recent post to the grass developer list that
> there is a richer interface description output called by "<command>
> --tcltk". This has been developed over the past year or so. I give an
> example below (part of the output from "d.vect —tcltk"). We might want
> to consider switching the autogenerated panels to be created by the
> —tcltk code.
>
> Besides being a richer set of descriptions (includes prompt for notebook
> tabs and color picking dialogs), it looks easier to parse than the
> —interface description xml. It would also mean that we would not need sax.
You are having problems parsing XML? Have you looked at the
xml.dom.minidom package? It provides a clean and easy DOM parser. If you
want I can write the parser (: (yay something I can do for the GUI).
Another, perhaps easier, alternative would be to add a --python flag
which would make the parser spew python code.
I've added guisection output to the XML generation in parser.c. While
looking for other weirdnesses in the different output formats, I came
across ->descriptions. So far, only --script makes use of them, and
I've grepped through vector/ raster/ and scripts/ and found that only
the following use it:
v.category
v.clean
v.drape
v.to.db
r.colors
For completeness sake, I would add ->descriptions handling in all of
HTML (where I think it is the most useful), tcltk and xml output, but
I wonder... Is there any chance of ->descriptions being more used?
Maybe add something in SUBMITTING and SUBMITTING_SCRIPTS?
I only discovered that they existed when I compared the XML and Tcl/Tk
code in response to this thread. The fact that --script actually
outputs them is an artifact of simply dumping every field of
"struct Option".
Note that G_parser() splits the ->descriptions field into individual
entries and stores the result in the ->descs field. The --help, XML
and HTML output all use that field. The Tcl/Tk code doesn't, though.
I followed that one. Having a (mostly) working wxPython GUI, I have
bumped into the problem of having waaaaaay too long descriptions that
are fed as labels in the GUI. I would propose the following:
- Have all the parser.c formats meant for human reading use
->description and ->descriptions. I mean actually help and HTML. I'd
say drop ->label, but haven't looked into them enough.
- The output formats meant for machines, namely xml and tcltk, should
include all the info, as raw as possible (i.e. splitting
->descriptions and adding them to ->description in XML is a no)
- For GUIs, use ->description for tooltips. Always. Use ->label for
widget labels if it exists. If not then chop ->description up to the
first punctuation character. So far, most very lengthy descriptions
I've seen are split in phrases. The standard options are really
eclectic in semantics for ->description vs. ->label. Those should be
fixed IMHO.
Then, add the corresponding cruft in SUBMITTING and start the janitorial work...
Having a (mostly) working wxPython GUI, I have bumped into the problem
of having waaaaaay too long descriptions that are fed as labels in the
GUI.
Then they are options which should get a ->label = "short description"
added to them. That's what ->label is there for (apparently). Note the
tcl GUIs will wrap long descriptions onto the next line if it looks like
they will collide with the "key_desc: gisprompt, required" text. Then
set a max/standard width & there's no problem.
Automatically breaking at the first punctuation char will lead to weird
breakage. Some people (like me) have a bad habit of using parenthetical
phrases mid-sentence. Better to craft it by hand with ->label if needed.
Chopping out info from ->description to make them shorter, without
relocating it to a tooltip and without losing meaning is very hard.
At minimum the info needs to be relocated into the help page.
I have updated the ->descriptions /* comment */ in gis.h to better
describe what that is for (describing the option's ->options=",").
I don't understand this:
char *guisection;
/* GUI Layout guidance: ';' delimited heirarchical tree position */
Descriptions can be wrapped too with wx.StaticText.Wrap
Michael
On 3/22/07 10:26 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Daniel Calvelo wrote:
Having a (mostly) working wxPython GUI, I have bumped into the problem
of having waaaaaay too long descriptions that are fed as labels in the
GUI.
Then they are options which should get a ->label = "short description"
added to them. That's what ->label is there for (apparently). Note the
tcl GUIs will wrap long descriptions onto the next line if it looks like
they will collide with the "key_desc: gisprompt, required" text. Then
set a max/standard width & there's no problem.
Automatically breaking at the first punctuation char will lead to weird
breakage. Some people (like me) have a bad habit of using parenthetical
phrases mid-sentence. Better to craft it by hand with ->label if needed.
Chopping out info from ->description to make them shorter, without
relocating it to a tooltip and without losing meaning is very hard.
At minimum the info needs to be relocated into the help page.
I have updated the ->descriptions /* comment */ in gis.h to better
describe what that is for (describing the option's ->options=",").
I don't understand this:
char *guisection;
/* GUI Layout guidance: ';' delimited heirarchical tree position */
so how is ";" used here?? (see lib/gis/gui.tcl)
Hamish
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
I don't understand this:
char *guisection;
/* GUI Layout guidance: ';' delimited heirarchical tree position */
so how is ";" used here?? (see lib/gis/gui.tcl)
You can specify nested subsections. AFAICT, the only option which
currently uses this feature is "g.region -g".
gui.tcl creates a separate frame (within the notebook page) for each
subsection. The end result is that any options within the same
subsection will be grouped.
You can see the effect more clearly if you modify the frame's
properties, e.g.:
--- gui.tcl~ 2007-03-23 20:25:13.000000000 +0000
+++ gui.tcl 2007-03-20 17:06:48.000000000 +0000
@@ -369,7 +369,7 @@
set parent_section [lrange $guisection 0 [expr [llength $guisection]-2]]
set parent_frame [layout_get_frame $dlg $parent_section $optn $glabel]
set id [llength [winfo children $parent_frame]]
- set suf [frame $parent_frame.fra$id -relief ridge -borderwidth 5]
+ set suf [frame $parent_frame.fra$id]
pack $suf -side top -fill x
return $suf
}