managing layer and properties

[Michael Barton]

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: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Michael Barton]

Are all of you folks on the GRASS GUI list, so that I won't have to have
such a long cc list for a general question?

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Jachym Cepicky]

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 <[hidden email]>:

> 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: [phone]
> fax: [phone]
> 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

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Michael Barton]

On 3/19/07 7:47 AM, "Jachym Cepicky" <[hidden email]> 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

>
> 2007/3/19, Michael Barton <[hidden email]>:
>> 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: [phone]
>> fax: [phone]
>> 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: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Moritz Lennert]

Michael Barton wrote:

> On 3/19/07 7:47 AM, "Jachym Cepicky" <[hidden email]> 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 <[hidden email]>:
>>> 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: [phone]
>>> fax: [phone]
>>> 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: [phone]
> fax: [phone]
> www: http://www.public.asu.edu/~cmbarton
>
>
> _______________________________________________
> grassgui mailing list
> [hidden email]
> http://grass.itc.it/mailman/listinfo/grassgui

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[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" <[hidden email]> wrote:

> Michael Barton wrote:
>> On 3/19/07 7:47 AM, "Jachym Cepicky" <[hidden email]> 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 <[hidden email]>:
>>>> 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: [phone]
>>>> fax: [phone]
>>>> 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: [phone]
>> fax: [phone]
>> www: http://www.public.asu.edu/~cmbarton
>>
>>
>> _______________________________________________
>> grassgui mailing list
>> [hidden email]
>> 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: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Glynn Clements]

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

> P.S. Yes, everyone except William (unless you also go under "woklist at
> kyngchaos.com")

I'm fairly sure that's him.

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[William Kyngesburye]

On Mar 19, 2007, at 1:25 PM, Glynn Clements wrote:

> Moritz Lennert wrote:
>
>> P.S. Yes, everyone except William (unless you also go under  
>> "woklist at
>> kyngchaos.com")
>
> I'm fairly sure that's him.
>
Yes, I let Michael know already.  It's my list address.

-----
William Kyngesburye <[hidden email]>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Jachym Cepicky]

hi,

2007/3/19, Glynn Clements <[hidden email]>:

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

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

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[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" <[hidden email]> wrote:

> hi,
>
> 2007/3/19, Glynn Clements <[hidden email]>:
>>
>> 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 <[hidden email]>
>>
>> _______________________________________________
>> grassgui mailing list
>> [hidden email]
>> 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: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Daniel Calvelo]

On 3/19/07, Michael Barton <[hidden email]> wrote:
[...]
> 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.

I've started looking into this. So far, it does seem easy to get a
gis.m-like interface. As Glynn pointed out, it remains to be seen
whether the current expressive power of --interface-description is
enough for correct user experience.

BTW, I'm striving at keeping menuform.py an independent component, so
tying it into the display manager should be done by inheritance from
menuform.py, or the latter be an instance of a more abstract
definition of a command builder.

[...]

Daniel.

--
-- Daniel Calvelo Aros

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Glynn Clements]

Daniel Calvelo wrote:

> > 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.
>
> I've started looking into this. So far, it does seem easy to get a
> gis.m-like interface. As Glynn pointed out, it remains to be seen
> whether the current expressive power of --interface-description is
> enough for correct user experience.

We can guarantee that it isn't enough for "ideal" user performance;
there currently isn't any way for the module to provide enough
information for that.

One problem is that the data types are far too limited; there are too
many cases where an option's type is just "string", with no further
qualification, because none of the other alternatives allow for all of
the acceptable values.

Another problem is that there is no way to indicate relationships
between options. Either an option is required or it isn't; there is no
way to indicate that you have to specify one option or another. In
this case, you just have to mark all options as "not required" then
have the code perform the checks. Similarly, you can't specify that
certain options are mutually exclusive, or that certain options have
to be used together.

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Michael Barton]

On 3/19/07 7:04 PM, "Glynn Clements" <[hidden email]> wrote:

>
> Daniel Calvelo wrote:
>
>>> 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.
>>
>> I've started looking into this. So far, it does seem easy to get a
>> gis.m-like interface. As Glynn pointed out, it remains to be seen
>> whether the current expressive power of --interface-description is
>> enough for correct user experience.
>
> We can guarantee that it isn't enough for "ideal" user performance;
> there currently isn't any way for the module to provide enough
> information for that.
>
> One problem is that the data types are far too limited; there are too
> many cases where an option's type is just "string", with no further
> qualification, because none of the other alternatives allow for all of
> the acceptable values.
>
> Another problem is that there is no way to indicate relationships
> between options. Either an option is required or it isn't; there is no
> way to indicate that you have to specify one option or another. In
> this case, you just have to mark all options as "not required" then
> have the code perform the checks. Similarly, you can't specify that
> certain options are mutually exclusive, or that certain options have
> to be used together.

These are some of the reasons that I favor more custom-designed
options/properties panels for displaying maps in the long run. However, we
can also ensure that these same panels pop up if you type d.rast or d.vect
from the command line.

Michael


__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Jachym Cepicky]

hi,

2007/3/19, Michael Barton <[hidden email]>:
> 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" <[hidden email]> wrote:
>
> > hi,
> >
> > 2007/3/19, Glynn Clements <[hidden email]>:
> >>
> >> 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 <[hidden email]>
> >>
> >> _______________________________________________
> >> grassgui mailing list
> >> [hidden email]
> >> 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: [phone]
> fax: [phone]
> 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

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Michael Barton]

AFAICT, it works fine. Try it out.

Once we have worked out how to get information from an autogenerated panel
back into the layer manager for processing, I'm thinking about replacing the
select map control (which will be redundant) with a transparency control.

Michael


On 3/20/07 8:05 AM, "Jachym Cepicky" <[hidden email]> wrote:

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

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui