On Aug 6, 2008, at 9:29 PM, Glynn Clements wrote:
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.
Good point. I'd thought about this but had forgotten it.
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?
Last time I checked, you could do g.region rast=map,map,map OR
g.region vect=map,map,map, but not g.region rast=map,map vect=map,map
Has this been enhanced to allow for simultaneous raster/vector specs?
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.
It is used to get the list of available fonts (from fontcap) to
present to the user in a list. Is there another way to get this list?
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.
This could probably be replicated as a command line python script
using MatPlotLib. The same code could be wrapped into the GUI to give
identical appearance with and without GUI.
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.
wxPython has a lot of graphic contexts and are adding more. I'm not
familiar with most of them. So I don't know if you could get something
similar enough to easily replicate this or not.
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.
It seems like we need some new modules (multiple rather than trying to
all in one like i.ortho.photo) that don't require interactive input,
which could then be wrapped into a GUI.
A chunk of i.ortho.photo interactive functions are replicated in the
current georectification module. If the parts specific to aerial
photos could be split out, the georectification wizard could add
appropriate pages for this info before going to the GCP screens.
I'm not sure how to best go about replacing i.class. One way to start
might be to use v.edit code, since we don't need large, complex vectors.
**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.
Agreed
Michael
--
Glynn Clements <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
