[GRASS5] starting discussion on next generation UI

[Glynn Clements]

Michael Barton wrote:

> - - - WISH LIST FOR GRASS UI - - -

One thing which you don't mention explicitly, but is quite important
IMHO, is that "real" GUIs are data-oriented (whereas tcltkgrass/d.m is
command-oriented).

In practice, this would typically mean, that you usually have a
"current" map, and this map would automatically be the primary input
for any operations requiring an input map. Also, the new maps created
by UI operations would be shown automatically.

Display should be much faster.

If maps are to be drawn using the existing d.* tools, they should be
drawn to PNG/PPM files which the display manager caches. Enabling,
disabling or re-ordering layers shouldn't result in any d.* commands
being executed.

[This is why the PNG driver supports PPM output with a PGM alpha
channel, and why g.pnmcomp was written. Unfortunately, the only masked
image format which Tk supports is GIF.]

Alternatively, the GUI needs to be able to perform all of the common
drawing operations natively.

> 4. If we end up keeping command dialogs, I¹d (usually) like them to go away
> after I click run‹with their output directed to the main control window.
> (This could get tricky running multiple processes, but should be solvable)

This should be trivial.

> I¹d like to have a button that brings up their last state when I open then
> so I could easily rerun something without having to keep the dialog open.

This should also be simple enough. The main reason why I split the
Tcl/Tk stuff in lib/gis/parser.c into G_gui() and G_tcltk() is so that
tcltkgrass/d.m gets a look in between the user clicking the Run button
and the command getting executed.

It wouldn't be much work to add e.g. a command history, where you can
retrieve the completed dialog state for any previous command. You just
need to override the default run_cmd procedure in gui.tcl with a more
complex version.

> 5. I wonder if there is a way to seamlessly combine NVIZ-like visualization
> with the Œstandard¹ displays so that all displays have the potential for
> 2.5D and 3D display and we don¹t have to run a special visualization module?

If you make NVIZ essential, GRASS will only work on platforms where
NVIZ works, i.e. those with Tcl/Tk and OpenGL libraries which can
coexist.

> 8. Users should be able to customize the UI to some extent, so that they
> could have the tools they use most often easily accessible, but wouldn¹t
> always have to wade through the entire tool set.

Allowing them to use a private version of menu.tcl would provide some
of that quite easily. A similar thing would need to be done for the
toolbar.

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