[GRASSGUI] Re: managing layer and properties

[Michael Barton]

Currently, addRaster assumes that you send it a mapname and arguments
(opacity, display options, etc). It then constructs a display raster comand
by adding d.rast. 

For matacontrols, the control would construct a valid GRASS command (e.g.,
[d.rast, map=elevation, catlist=1-600, -o] to use a list rather than a
string). This would simply be passed on to the rendering engine.

This is the way it works now for the command layer. There is no way for the
addCommandLayer method to know in advance which GRASS command to use, so it
just accepts whatever comes from the command layer and sends it on to
__renderCommandLayer, which in turn send this on to the command processor.
For a metacontrol approach, we should do the same thing.

Glynn makes some solid arguments for taking the autogenerated gui approach.
However, if we can echo any command processed to the output console
(regardless of whether it is done by a single command control or a
metacontrol) it makes the underlying command structure transparent to the
user. Conceptually I like the metacommand approach, but I also understand
the points that Glynn and Moritz have made for the alternative.

In terms of the most effective use of our time, I'd propose the following.
Why don't we start with using the existing autogenerated gui panels--and
upgrading menuform to make it nice (use select.Select for maps and other gis
elements, add notebook tabs and icons like in the TclTk GUI, etc). The
latter needs doing anyway. Taking this route first, I think that we could be
up and running very quickly with a full-featured wxGRASS in short order. The
sooner we have something that is 80%+ useable, the sooner we can have
widespread testing, and maybe get some additional help in writing the
separate modules for georeferencing, profiling, and the like.

While this first version is in testing and fleshing out, someone(s) can work
on a prototype metacontrol properties dialog and see how it goes. As you've
envisioned it Jachym, it could wrap considerably more than display commands,
including r.colors and r.support for example. This will take some time to
develop and test, but could easily be plugged in when ready.

Thoughts?

Michael


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

> hi,
> 
> 2007/3/19, Glynn Clements <glynn at gclements.plus.com>:
>> 
>> Moritz Lennert wrote:
>> 
>>>> 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.
> 
> Sorry, but I do not get this point: Raster layer has nothing common
> with Vector layer, which has nothing common with (e.g. in the future)
> WMS layer... Could you post example for these three layer-types, how
> they should be rendered?
> 
> 
>>> 
>>> 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.
>> 
>> Apart from code maintenance issues, you're isolating the user from the
>> d.* commands. Someone who normally uses the GUI may have no idea how
>> to achieve the same results from the command line or in a script.
>> 
>> Also, if the custom raster and map layers contain useful functionality
>> which isn't available via d.rast, d.vect etc, that shouldn't be
>> reserved for GUI users, but should also be available from the command
>> line.
> 
> I hope, I found a way  for this (in svn now):
> 
> mapdisp.py can be started with path/to/command/file as argument
> 
> mapdisp.py will then read the file and if there is something new in
> it, it will try to process it:
> 
> cmdfile=open("cmdiflename",r)
> while 1:
>    line = cmdfile.readline()
>    if line:
>        # there is display command, add new layer and redraw display
>    sleep(0.1s)
> 
> I scripted p.mon , p.rast and p.vect scripts, which can start &&
> display the data. p.vect and p.rast siply formulate string, which is
> echoed to the cmd file.
> 
> I tried to udpate the README, so you can follow these steps.
> 
> I hope it is working, it is working on every platform and it is more
> or less clean..
> 
> Glynn, what do you think about this idea?
> 
> Jachym
> 
> 
>> 
>>> P.S. Yes, everyone except William (unless you also go under "woklist at
>>> kyngchaos.com")
>> 
>> I'm fairly sure that's him.
>> 
>> --
>> Glynn Clements <glynn at gclements.plus.com>
>> 
>> _______________________________________________
>> 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