[GRASS-dev] Python GUI toolkits

[David Finlayson]

On 6/8/06, Hamish <hamish_nospam at yahoo.com> wrote:
> IMO we should pick a GUI language based on its long term merits, not
> because we have a nice editor for one. Fast development is nice, but
> lack of bug reports is much nicer. (especially if they are upstream
> bugs)
>

Indeed. WIth the exception of Visual Basic, I've always built GUI code
by hand. In the end it makes for cleaner code. Here (wxpython or
pygtk) widgets and event handlers are rarely more than a few lines of
code each anyway.

Mark Lutz's book on Programming Python (a classic now) has some nice
examples of programming GUI code in Tcl/tk. He shows how to use mixen
classes to wrap up the tedious parts of the GUI construction. There
are two advantages:

1. Common objects are easy to instantiate with sensible defaults
2. More importantly, you isolate the program from the underlying GUI
implementation so that the GUI toolkit can be changed in the future by
modifying the mixen class methods in one place (for example, when GTK
becomes native on OS X) without modifying the main program calls.

Python is about 80% lisp now. Which means you can write meta programs
that write programs. Its a powerful concept once you start working
with it.


Hammish:

>
> FWIW, I really like the Matlab language & engine but I hate the 6+ GUI
> command interface. I run it -nojvm from my normal rxvt terminal window
> with nedit in Matlab mode for the editor. For me, I need to focus when
> working with it and a cluttered command window really hurts that.
> It doesn't help that the Java interface is slow, buggy, and the fonts
> horrible. I don't know R so well, so there the GUI version is a nice
> crutch -- I can see the advantage to the concept.
>
>

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.

My idea is to combine the best of both worlds. Focus on the CLI so
that the user only learns the tool one way. But make it discoverable.
For example, the GUI-IDE thing could have a tree view of all the
available programs organized by task. An executable index to all grass
programs. A browser for locations/mapsets, etc. Use the same tool to
drag-and-drop a simple script in the built-in editor.

This is a different paradigm than a full-on GUI like is found on Qgis.
We can implement different GUIs for GRASS 7 and see which one becomes
popular enough to support in the main distribution.