[GRASS-dev] Python GUI toolkits

[Glynn Clements]

David Finlayson wrote:

> In my opinion, one of the problems with a GUI is that you have to
> learn GRASS twice to use it in scripts. Once, you learn the buttons
> for getting things done. Twice, you learn the commands to do the same
> thing. That makes scripting a high barrier to cross and a lot of
> people never learn how to automate there work. In CLI, you only learn
> the program once, you use the same command for interactive and
> scripting use. Just like the big math programming languages. This must
> work because all of the big math programs use this approach (Matlab,
> Maple, Mathematica, R, S-plus, etc.) and many of these are popular
> with their users.
> 
> BUT, the main problem with the CLI is discoverability. You can't use
> it if you don't know the commands and weak CLI do not assist in the
> tedious usage parts. And there are some things that are just easier
> when interactive, like laying out a figure. So, a nice IDE can really
> make using the program easier by providing helper tools that make the
> CLI friendlier and more discoverable.

For GRASS, the main problem with a command line is that specifying
points by typing in coordinates is a lot less convenient than using a
mouse.

Modules such as v.digit and i.points /need/ a GUI.

Beyond that, the visualisation aspects of gis.m should ultimately be
able to be controlled from the command line. I.e. being able to type a
command to add, move, modify, hide (etc) layers, rather than having to
use buttons or menus.

Even from a command-line perspective, the existing display
architecture is deficient in that you can't modify the layer stack
other than adding a new layer on the top or clearing the stack
altogether.

-- 
Glynn Clements <glynn at gclements.plus.com>