[Gretl-users] Menu re-structuring

[Allin Cottrell]

On Thu, 13 Jul 2006, Riccardo Jack Lucchetti wrote:

> While we're at it, would anyone else like to have a tab under 
> the "Preferences" dialog to set all the switches that currenly 
> are only accessible through the "set" command, such as 
> "hplambda"? By the way, this would enable us to get rid of the 
> "seed generator" entry under "Add", that doesn't really belong 
> there IMO.

Amen.  Here's the deal:

Someone has to design a data structure to hold all the 
information on the preferences in gretl's libset.c.  This 
structure should be flexible enough to make it fairly easy to 
add new "set" elements (something we've done a fair amount 
lately), yet explicit and uniform enough to permit a simple, 
algorithmic formulation of the GUI elements that compose an 
"Advanced" Preferences dialog box.

The GUI code has to be able to interface with libset and say 
something like: "How many things should I provide for the 
setting of?".  "OK, got it.  Now, for the i'th thing to be set, 
should it be a boolean, an int, a matrix, a structure with (how 
many did you say?) elements."  "Ah, and what are the limits to 
the thing to be set: does it have to be positive (e.g. if an int 
or a double)? And what string should I present to the user as 
the label of this thing?"

The GUI has to be able to figure out, for each settable thing 
(or sub-thing), what is the appropriate interface: a spinner 
(with what range/limits?), a drop-down selector (from what 
domain of selection?), a textual entry field (of what maximum 
length?), ...

GUI design 101: A dialog box should, ideally, be constructed 
such that it's simply impossible for the user to create invalid 
input.  Failing that -- if the data entry "just has to be" 
relatively free-form -- the input should be checked immediately 
for validity, and if it's bad the GUI should come back with an 
informative error message and take the user back to the 
particular step where something went wrong (with an option to 
Cancel if the user can't be bothered to figure it out).

The last time I used Eviews I found that it egregiously violated 
this principle.  I would get to step N in something fairly 
complicated then get a box saying something like "Error: invalid 
input" and be dumped back to square 1, with no indication of 
what was wrong with the input.  This is a bad user experience. 
I don't want to create a GUI for libset until we're reaady to do 
it right.

It's not brain surgery, but it is quite time consuming.  Any 
volunteers?

Allin.