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

["Fernández-Victorio Arévalo, Gonzalo"]

Some comments follow before starting with the RFC:

RADIM > I can see from time to time long discussions
RADIM > about GUI for grass. 

I agree. For example, from april-2001 to date, more than 5.8% of the
messages of this list have the word "GUI".

It seems that GRASS GUI is not as good as it should be.

GLYNN > too much of
GLYNN > GRASS' code was written without any consideration as to how it fits
GLYNN > into the whole.

Again, I agree. Grass has many years and it has evolved "scratching many
one's personal itch"(Sorry if that isn't correct in English)

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. 

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.

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)

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

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.
	+If the user drops an image, we(the GUI) open a window asking
her/him for parameters, and then call the import module with the options, to
import into GRASS database.

What if instead of two versions of the same programs (command and inter), we
have just commands.

What we need:

	+We need some toolkit portable. Grass is portable and should stay
like this...
	+... but I don't mind if we specify something common. I mean, it
seems to be a hell the number of versions (and incompatability betwwen them)
of TK/TCL.
	+The toolkit shouldn't give problems like linkining against C. (Yes,
I agree C++ it's A Bad Thing (TM))
	+Although I'm not particularly strict with this, the toolkit should
be free in the sense of freedom.
	+I thing we should abstract the toolkit.
	+We need to know and detail what every module should recieve,
(related to monitor-window/layer...),and what every module could say.
	+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.


Hope this helps:


Gonzalo