[GRASSGUI] Re: managing layer and properties

[Michael Barton]

It would require changing the code if a d.* command changes its syntax. This
is how it works now in TclTk.

This does involve manual maintence of the GUI code. However, it may sound
like a lot, but it's really not as bad as it seems. There is a pretty
strictly enforced rule to not change the syntax of grass commands in a way
that would break anything between major releases (i.e., you can add stuff,
but you can't get rid of an option or make it do something radically
different). This makes maintenance fairly minimal in reality. The worst case
recently was the set of changes made to g.region flags. They crashed the
GUI, but also wreaked havoc elsewhere and were reverted. OTOH, it was very
easy to alter the GUI code to accommodate them once I knew what had been
done.

This is not a strong argument for one direction or another, but just to
point out that most of the work would be in creating the properties
metacontrols, not in subsequent maintenence. There will be equal work in
making any autogenerated GUI work nicely for the layer management. Changes
to grass commands could break these too, requiring maintenance of a
different kind. I don't know which is a bigger investment. But we should
strongly consider which will provide the best user experience too.

Michael


On 3/19/07 9:11 AM, "Moritz Lennert" <mlennert at club.worldonline.be> wrote:

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

__________________________________________
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