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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev