[GRASS-dev] WxPython prototype GRASS GUI. Version 2

[Yann Chemin]

Thanks Michael,
:-)
Looks good!


On 08/08/06, Michael Barton <michael.barton at asu.edu> wrote:
> Yann,
>
> Just tried  your menu in more detail. You no longer have to add the
> --interface-description | python grassgui.py after each command. Just put in
> the command. gism.py and the command parser does the rest.
>
> I uploaded it again with this fixed.
>
> Michael
> __________________________________________
> 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
>
>
> > From: Yann Chemin <ychemin at gmail.com>
> > Date: Tue, 8 Aug 2006 04:27:24 +0700
> > To: Michael Barton <michael.barton at asu.edu>
> > Cc: Grass Developers List <grass-dev at grass.itc.it>, Markus Neteler
> > <neteler at itc.it>
> > Subject: Re: [GRASS-dev] WxPython prototype GRASS GUI. Version 2
> >
> > On 08/08/06, Michael Barton <michael.barton at asu.edu> wrote:
> >>
> >>
> >>>
> >>> I'd like to think we can make a C code to automatically create a menu
> >>> description file instead of making it by hand all the time. If you
> >>> could separate it well from the other coding, it should make that task
> >>> easier when we'll come to it.
> >>
> >> Making the description file should be fairly easy. It could even be done in
> >> Python, using the xml output from [grass-command] --interface-description.
> >> The complicating factor is where to put each menu item in some kind of a
> >> meaningful arrangement. The latter probably needs to be human organized to
> >> work best. However, it could perhaps be semi-automated if we could make some
> >> kind of organized menu template (xml file?) by hand and an automated
> >> procedure could fill in the gory details.
> >>
> > Yes, something like this, a kind of meta-level. Think about
> > hydrological related modules could be self identified by the internal
> > description or keywords that Markus mentioned. Then you could "switch
> > on" this group, then all modules answering to the call could be
> > grouped into the same dialog and it could then be available at a
> > higher place (i.e. very visible) in the GUI layout.
> >>>
> >>>
> >>> Additionally, since Python GUI does not need recompiling, it should
> >>> then be possible to generate "flavors" of GRASS, i.e. for image
> >>> processing or for GIS analysis, etc on the fly by modifying menu
> >>> contents.
> >>
> >> Yes. But I'm betting that most people will want it all.
> >
> > Yes they want it all, but they also want to find easily what they use
> > more commonly, i guess all can be there at all times, it is just how
> > the users choose the visibility of their "pet" groups of
> > modules/submodules/specific functions.
> > :-) (head-scratching ...)
> >>
> >> Michael
> >> __________________________________________
> >> 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
> >>
> >>
>
>