[GRASSGUI] Re: managing layer and properties

[Michael Barton]

On 3/19/07 7:47 AM, "Jachym Cepicky" <jachym.cepicky at gmail.com> wrote:

> Hi,
> 
> I agree, that it would be better to creat our custom layer-properties
> window. It will be more difficult way, but at the end,we should have
> more rich settings possibilities and that is, what the users are
> asking ....
> 
> We can add new methods to render py (beside "simple" AddRasterLayer &
> co.) or add new attributes to existing ones - that is no problem. We
> just need to define following things:
> 
> * What layer types will we have
> * What attributes should each layer have
> 
> Jachym

Jachym,

If we go the metacontrol route, we only need one method in render.py--one
that will accept a fully formed command with all arguments. I already did
this in order to make a command layer work.

The metacontrol would construct the fully formed command--based on user
selections in the properties (e.g., a r.colors command if changing the color
table), and send it on to render.py.

Michael


> 
> 2007/3/19, Michael Barton <michael.barton at asu.edu>:
>> Here is a chance to rethink how map display is presented to users in the
>> GUI.
>> 
>> In the TclTk GUI, there is pretty much one layer type for each d.* command.
>> This works, but is complicated to maintain the various options panels. So
>> here are a couple thoughts on how to make this better.
>> 
>> Glynn suggested that we simply use the autogenerated options dialog for each
>> d.* command and make these better as needed. In fact, I've committed a
>> version of gismutils.py that does just that (although it doesn't yet work
>> for setting any options in layers.). In this way, we would still have a
>> layer type for each d.* command we want to include, but would not have to
>> individually maintain an options panel for each as the commands and their
>> options are changed in the future. We'd need to put considerably more effort
>> into mapform.py, especially for how it presented complex d.* commands like
>> d.vect, to make it less daunting.
>> 
>> An alternative is to have only one raster and one vector properties panel.
>> Each panel would offer the range of display options for raster and vector
>> maps accordingly. For example, the raster panel would have options for
>> draping color over shaded relief maps, combining rgb/his maps, displaying
>> cell values or flow arrows. We could maintain a separate, attached canvas
>> for raster or thematic vector legends. The user would only add a raster or a
>> vector map, then decide on how to display it.
>> 
>> This would simplify some aspects of the UI. But it would be some effort to
>> build these metacontrols. If we went this way, we would need to simplify how
>> render.py works. Currently, the actual commands are supplied in render.py.
>> If we went with a combined property window for rasters and vectors, this
>> metacontrol should generate the actual command, depending on how the user
>> wants to display a map (e.g., use d.rast, d.rgb, d.his, etc.). This is more
>> the way that arcgis and qgis present to the user. Although the control would
>> be complex, it offers more chance for custom explanations and help.
>> 
>> Anyway, I want to run this by you for my overnight.
>> 
>> Michael
>> 
>> 
>> __________________________________________
>> Michael Barton, Professor of Anthropology
>> School of Human Evolution & Social Change
>> Center for Social Dynamics & Complexity
>> Arizona State University
>> 
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>> 
>> 
>> 
> 

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton