Michael Barton wrote:
Here are some comments from the GUI side, and some personal
observations. *indicates importance for GRASS 7.
d.colors - Not used much but some useful tools for modifying color
tables. Maybe the underlying code is useful for this?
This is a prime candidate for being replaced by a wxPython script.
Something that lets you interactively edit colour rules, displaying a
legend (generated by d.legend or internally) which is automatically
updated whenever the rules are changed, and optionally displaying a
preview of the map which is likewise updated automatically.
IOW, a combination of a GUI front-end to r.colors and a replacement
for d.colors.
d.extend - It would be nice to get this functionality with g.region
rast=map,map,map vect=map,map,map
Don't we have that already?
d.extend just used the lists of raster and vector maps displayed on
the monitor. As there are no longer monitors (and there is no
persistent state with immediate rendering), d.extend is no longer
meaningful.
**d.font - This is used in the GUI to set the screen font.
No it isn't; it doesn't work with immediate rendering, as there is no
persistence of state between d.* commands. Immediate rendering uses
the GRASS_FONT and GRASS_ENCODING environment variables.
We need the equivalent of this function
There may be some merit to changing GRASS_{FONT,ENCODING} to $GISRC
variables. This would be easier from the command line, as you could
still have a d.font script which is essentially:
g.gisenv set=GRASS_FONT=$GIS_OPT_FONT
OTOH, the GUI would then need to use a temporary $GISRC for all
display commands rather than just using a temporary environment.
Between the two, I think that the GUI comes first on this.
d.frame - Everyone agrees that cartography functions are very
desirable. But this module was too primitive
It also suffers from the same lack-of-persistence issues as d.font,
i.e. any frame has to be created by the module which uses it.
It's also problematic for vector output (PS/PDF/SVG), as the notion of
"resetting" the clip region violates the principle of encapsulation.
Ideally, frames should nest (begin, draw, end).
d.profile - Replicated GUI
This one should ideally be available as a d.* command. The main
obstacles are the use of the mouse to indicate transects, and the
extensive use of frames. Neither of those are fundamental issues; it
should be feasible to cannibalise d.profile into a non-interactive
module.
d.rast.edit - Replicated in TclTk but not in wxGUI
Re-writing this wouldn't be a vast amount of work. The main issue is
whether to implement the cells as individual widgets or to just
provide redraw/motion/click handlers for a drawing canvas. AFAIK, wx
doesn't have anything like Tk's canvas where you can add persistent
graphic objects which redraw themselves and report enter/leave events.
d.save - I believe still used in d.out.file, along with d.mon. This
script is no longer functional
Okay, I've removed d.out.file.
d.what.rast - Replicated with GUI wrapper for r.what
d.what.vect - Replicated with GUI wrapper for v.what
d.where - Built into GUI canvases
I have wondered whether there's any point in cannibalising these as
non-interactive programs which accept x/y screen coordinates as
arguments.
g.ask - Not sure what it does
It's sort of an interactive version of g.findfile:
$ g.ask type=old element=cell unixfile=out.txt
Enter the name of an existing cell file
Enter 'list' for a list of existing cell files
Hit RETURN to cancel request
>
i.ask - Not sure what it does
Fancy version of d.menu.
**i.class - This seems important. Not replicated in GUI.
**i.ortho.photo - Important. Not replicated in GUI
Important or not, i.class is fairly complex, i.ortho.photo is very
complex. Both are substantial GUI applications using curses and
libraster as a GUI toolkit.
Even a crude hack job (like the conversion of v.digit to Tcl/Tk) would
be a fair amount of work. It would be better if someone who understood
the processes involved were to re-design the UI from scratch. I would
expect that any non-trivial UI built with curses and libraster is
bound to have significant usability defects.
**r.support - Need some way to access raster metadata.
Of the four sub-modules:
modhead -> r.region
modcats -> r.category
modcolr -> r.colors
modhist -> ???
The functionality built into the front-end module is mostly
non-interactive, and can be cannibalised.
So that just leaves editing the history. The obvious non-interactive
solution is a module (or two) which allows the history to be read from
or written to a text file.
--
Glynn Clements <glynn@gclements.plus.com>