[GRASSGUI] 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

[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

[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

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

[Michael Barton]

Post by 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
* 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

Post by Jachym Cepicky

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

__________________________________________
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

[Moritz Lennert]

Post by Michael Barton

Post by 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
* 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"

Post by Michael Barton

Post by Jachym Cepicky

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

__________________________________________
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
http://grass.itc.it/mailman/listinfo/grassgui

[Glynn Clements]

Post by Moritz Lennert

Post by Michael Barton
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.

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

I'm fairly sure that's him.

[William Kyngesburye]

Post by Glynn Clements

Post by Moritz Lennert
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 <***@kyngchaos.com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

[Jachym Cepicky]

hi,

Post by Glynn Clements

Post by Moritz Lennert

Post by Michael Barton
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?

Post by Glynn Clements

Post by Moritz Lennert
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

Post by Glynn Clements

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

I'm fairly sure that's him.
--
_______________________________________________
grassgui mailing list
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

Post by Moritz Lennert

Post by Michael Barton

Post by 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
* 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"

Post by Michael Barton

Post by Jachym Cepicky

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

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

[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

Post by Jachym Cepicky
hi,

Post by Glynn Clements

Post by Moritz Lennert

Post by Michael Barton
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?

Post by Glynn Clements

Post by Moritz Lennert
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.

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
cmdfile=open("cmdiflename",r)
line = cmdfile.readline()
# 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

Post by Glynn Clements

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

I'm fairly sure that's him.
--
_______________________________________________
grassgui mailing list
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

[Daniel Calvelo]

On 3/19/07, Michael Barton <***@asu.edu> wrote:
[...]

Post by Michael Barton
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.

[Glynn Clements]

Post by Daniel Calvelo

Post by Michael Barton
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.

[Jachym Cepicky]

hi,

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

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

Post by Michael Barton
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.

Post by Michael Barton

Post by Jachym Cepicky
hi,

Post by Glynn Clements

Post by Moritz Lennert

Post by Michael Barton
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?

Post by Glynn Clements

Post by Moritz Lennert
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.

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
cmdfile=open("cmdiflename",r)
line = cmdfile.readline()
# 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

Post by Glynn Clements

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

I'm fairly sure that's him.
--
_______________________________________________
grassgui mailing list
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

[Michael Barton]

Post by Glynn Clements

Post by Daniel Calvelo

Post by Michael Barton
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

[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

Post by Jachym Cepicky
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