[GRASSGUI] Re: managing layer and properties

Tue Mar 20 11:05:40 EDT 2007

hi,

2007/3/19, Michael Barton <michael.barton at asu.edu>:
> 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.

Just to be sure: current status of AddComandLayer is sufficien for
you? Anything to be added/removed/enhanced?

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

I aggree with this. We should build it slowly up. Using existing
tools, which are just working, even if they do not "look" like we
would like, is good think. We can add new controll windows in the
future.

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

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