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

[Paul Kelly]

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.

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

Paul