[GRASSGUI] wxgrass gui status: was [GRASS-dev] Vect_snap_lines (list of lines)

[Michael Barton]

On 5/13/07 6:28 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> On Sat, 12 May 2007, Daniel Calvelo wrote:
> 
>> On 5/12/07, Glynn Clements <glynn at gclements.plus.com> wrote:
>> [on dumping tcl's menu structure to python]
>>>> But sadly, I would be able to cut and past the commands in
>>>> less time than it would take me to figure out such a script.
>>> 
>>> Can you give an example of the required Python syntax?
>> 
>> It's in gui_modules/menudata.py and is modelled after gmmenu.tcl. It's
>> just 4-tuples of strings (label, description, python command called,
>> grass module), where all four empty means a separator. These are
>> arranged in a tree (of tuples, but arrays would do) corresponding to
>> the menu structure, as pairs of ("menu entry",child) with child being
>> either a 4-tuple of entries or another pair.
>> 
>> The only tricky part is in those commands that require internal work
>> by tcl (mostly the first menu item); the rest are mainly
>> correspondences between menu items and grass commands.
>> 
>> I'd do that using a simple protocol (coding the python- ot
>> tcl-specific parts as special codes) to access a configuration file in
>> JSON, XML or tab-indented specifications. Not much time to do that
> 
> I think I agree, in so far as it would be nice to have the command
> description stuff separated out in a separate file (rather than hard-coded
> into the GUI) to allow e.g. documentation, lists of useful commands to be
> generated automatically from it. ISTR also somebody pointing out that the
> GUI menus tended to obscure which GRASS module it was you were actually
> running (of course it's visible when you open the auto-generated GUI
> dialog, but not from the GUI menus, in gis.m anyway) - having the
> correspondence between the menus and the commands in a separate file might
> also make it easier to document this, with a bit of scripting.

The menus *are* in a separate file for both TclTk and wxPython. When you
mouse over a menu item in TclTk, the command name shows up in the GIS
Manager status bar. This does not happen in wxPython (yet), but when you
select a menu item and show its GUI dialog, the name of the command and any
options you select show up in the dialog status bar, and the command help
file is built into the dialog as one of the tabs. So there is quite a bit of
transparency between GUI and commands already built in for those who want to
take advantage of it.

> 
> I don't have any definite ideas on *exactly* how it would be done though,
> just that it is a good idea in principle.

This is the fundamental issue at the moment. We all agree that a better way
to manage the large and complex menu structure is a good idea, but no one is
able to take on this task at the moment. To get wxPython to full testing
status, we need to get all the commands into the menu. I suggest we just do
it the old fashioned way at the moment and continue work on a better way to
work with menu management as the project develops.


Michael 

__________________________________________
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