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

[Michael Barton]

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