[GRASS-dev] Re: 7.x Status Update (Glynn Clements)

[Michael Barton]

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 <glynn at gclements.plus.com>