[GRASSGUI] Re: managing layer and properties

[Moritz Lennert]

Michael Barton wrote:
> 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


I don't know enough of the internals to judge, but it sounds like this 
will make the code much more difficult to maintain, especially since it 
will require regular and significant manual interventions ? Intuitively, 
I would rather plead for Glynn's suggestion.

Moritz

P.S. Yes, everyone except William (unless you also go under "woklist at 
kyngchaos.com") is on the mailing list. You can check this by going to 
http://grass.itc.it/mailman/listinfo/grassgui and "Visit the Subscriber 
List"

> 
> 
>> 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
> 
> 
> _______________________________________________
> grassgui mailing list
> grassgui at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassgui