changing data for parser

5 messages Options
Embed this post
Permalink
Michael Barton

changing data for parser

Reply Threaded More More options
Print post
Permalink
Some javascript/style in this post has been disabled (why?)
changing data for parser 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
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Wolf Bergenheim

Re: [GRASS-dev] changing data for parser

Reply Threaded More More options
Print post
Permalink
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.

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Daniel Calvelo

Re: changing data for parser

Reply Threaded More More options
Print post
Permalink
In reply to this post by Michael Barton
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 <[hidden email]> 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
> [hidden email]
> http://grass.itc.it/mailman/listinfo/grassgui
>
>


--
-- Daniel Calvelo Aros

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Jachym Cepicky

Re: Re: [GRASS-dev] changing data for parser

Reply Threaded More More options
Print post
Permalink
In reply to this post by Wolf Bergenheim
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 <[hidden email]>:

> 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.
>
> --Wolf
>
> --
>
> <:3 )---- Wolf Bergenheim ----( 8:>
>
> _______________________________________________
> grassgui mailing list
> [hidden email]
> http://grass.itc.it/mailman/listinfo/grassgui
>


--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Glynn Clements

Re: changing data for parser

Reply Threaded More More options
Print post
Permalink
In reply to this post by Michael Barton

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".

AFAICT, --interface-description is simply missing the ->guisection
field. There's no reason why that field cannot be added.

I don't see any point in using the --tcltk output for Python code.

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui