[RFC] GUI & GRASS 51 (was RE: [GRASS5] g51 v.digit)

[Glynn Clements]

Fernández-Victorio Arévalo, Gonzalo wrote:

> GLYNN > The last thing that anyone should be doing in that area is coding.
> GLYNN > That's how we got into this mess in the first place;
> 
> I'm afraid that I don't completely agree with this. 

Possibly because you took it out of context. The phrase "that area"
referred to the overall display architecture, not individual
applications (e.g. v.digit).

> I think that we shouldn't code the "GUI" (whatever it should be) until we
> decide what to do, but IMHO we shouldn't stop the development in other areas
> because it doesn't conform with the planned GUI. If somebody needs to code
> (say v.digit) and it doesn't behave the way it should be, it'll have to be
> changed later, as many other modules.

That's almost exactly what I was saying, although the two aspects
(short term issues with coding individual applications, and the longer
term issue of a framework for interactive applications) seem to have
become mixed-up.

> The rest of the mail will try to explain my vision about the GUI. It isn't
> very new, but anyway I've decided to write it down. Quoting Glynn again:
> 
> GLYNN > So, we're basically
> GLYNN > looking for a UI with plug-ins.
> 
> I think that's the key element. In IDRISI, (I don't know if it still works
> like this) you had a nice GUI with menus that opened windows where you could
> select options and when done you clicked on "OK". Then a command was
> launched with the options you had selected. 
> 
> With a design like this you have the power of command line(that I think we
> shouldn't loose), and a nice GUI, which is something needed. And if you want
> to translate GRASS, you just have to translate the GUI, (the modules
> shouldn't want to "say" nothing beyond pure "OOPS"/CoreDump. Errors should
> be recieved by the GUI)

To an extent, we already have this with tcltkgrass. However, it only
works well for non-interactive ("fire-and-forget") programs. Even then
there are problems with programs that decide to ask questions of the
user half-way through, via the terminal.

> OK. I know. That isn't so new. In fact, seems to be close with what we have
> in NVIZ. 

Actually, NVIZ is closer to the classical monolithic GUI application.

> Then, let's follow it to the extreme. 
> 
> For example, with the case of v.digit (I don't know if it is possible, but
> it shows what I mean), what if instead of calling a function to get the
> position we had a program that breaks lines and some of the options where
> position_x, position_y, and even "monitor" (seems obvious that we should
> have some other infraestructure), and ¿"layer"?. 
> 
> In the troubly case of a zoom, it would be something like pos1_x, pos1_y,
> pos2_x, pos2_y, type_of_zoom(zoom, pan, zoom_normal), window (or
> environment, or draw or ... monitor).
> 
> And then the GUI would react to events. Something like the following
> examples:
> 
> 	+If the user clicks on this menu, we(the GUI) open a window, ask
> him/her for options, and then launch that other
> 	+If the user clicks on that other menu, we(the GUI) change the
> mouse, recieve one click, draw a rectangle, recieve one click, launch
> command zoom.

That's a modal approach, which is what I'm trying to get away from. In
a more typical GUI application, it would work more like:

1. The user selects the "rectangle" button from the toolbar.
2. The user marks a rectangle on the display.
3. The user selects the "zoom" option from the menu.

Normally, you select first, then apply one or more commands to the
selection. This allows for applying multiple commands to a single
selection.

The whole issue with modality is that it restricts the user to those
choices which are explicitly made available in the current "mode".

It's preferable if the user can choose any option at any time. E.g
while in the middle of digitising a path, the user ought to be able to
zoom the map, look at another map, bring up help, etc. The only
options which *shouldn't* be possible are those which can't
realistically be implemented (e.g. operations which require a path
when no path is selected).

> 	+We need to know and detail what every module should recieve,
> (related to monitor-window/layer...),and what every module could say.

Interface. This is the key problem, and the reason why you need to
work out the design before starting to code.

> 	+Maybe we should need a fixed and powerfull options sintax for every
> module, that facilitates the generation of the GUI. We have something like
> this, but I don't know if that's fine.

Well, there seems to be a consensus that extending the option parser
is a good idea. But that's mostly applicable to non-interactive
commands.

-- 
Glynn Clements <glynn.clements at virgin.net>