[GRASSGUI] Re: managing layer and properties

Jachym Cepicky jachym.cepicky at gmail.com
Mon Mar 19 10:47:13 EDT 2007


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

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
>
>
>


-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub




More information about the grass-gui mailing list