[GRASSGUI] opacityDialog

[Martin Landa]

Hi Michael,

maybe it would be better to use for changing layer opacity level
instead of wx.SpinCtrl *wx.Slider*. The attached patch shows one of
the way (not so elegant) how to do it.

Popup Menu -> "Change Opacity" -> opacity ialog

What do you think?

Martin
--
Martin Landa <***@gmail.com> * http://gama.fsv.cvut.cz/~landa *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opacityDialog.diff
Type: application/octet-stream
Size: 11530 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-gui/attachments/20070523/29d6a12c/opacityDialog.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opacityDialog.png
Type: image/png
Size: 21052 bytes
Desc: not available
Url : Loading Image...

[Michael Barton]

I did try that and here's why I went to a spinner.

I like sliders. But...the slider looks bad (doesn't format quite right) and
takes up a lot of room (at least on my Mac version) when used in a
customtreectrl.

I love contextual menus, but strongly resist putting something there that is
not also available elsewhere (i.e., with a left mouse click). To do
otherwise means that it is visually hidden and the user has to know that it
exists a priori in order to use that feature. To the best of my knowledge,
this is contrary to standard interface guidelines.

So this would mean putting an 'opacity' popup button somewhere--either in
the properties dialog or in the tree item line and then creating a text
object that would need to be updated dynamically every time the opacity
control is changed. I decided that a spinner was easier to implement than a
button and some kind of text that would need to be updated (always tricky).
It offers direct user access to the function. You can type or spin, it
offers direct user feedback to the state of opacity without any updating
code.

Michael

Post by Martin Landa
Hi Michael,
maybe it would be better to use for changing layer opacity level
instead of wx.SpinCtrl *wx.Slider*. The attached patch shows one of
the way (not so elegant) how to do it.
Popup Menu -> "Change Opacity" -> opacity ialog
What do you think?
Martin

__________________________________________
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

[Martin Landa]

Michael,

Post by Michael Barton
I did try that and here's why I went to a spinner.
I like sliders. But...the slider looks bad (doesn't format quite right) and
takes up a lot of room (at least on my Mac version) when used in a
customtreectrl.
I love contextual menus, but strongly resist putting something there that is
not also available elsewhere (i.e., with a left mouse click). To do
otherwise means that it is visually hidden and the user has to know that it
exists a priori in order to use that feature. To the best of my knowledge,
this is contrary to standard interface guidelines.
So this would mean putting an 'opacity' popup button somewhere--either in
the properties dialog or in the tree item line and then creating a text
object that would need to be updated dynamically every time the opacity
control is changed. I decided that a spinner was easier to implement than a
button and some kind of text that would need to be updated (always tricky).
It offers direct user access to the function. You can type or spin, it
offers direct user feedback to the state of opacity without any updating
code.

OK, on the other hand I feel wx.SpinCtrl in layer tree as a
"disturbing" feature. I think there is place only for 'layer name'
and checkbox (enable/disable). The widget for setting transparency can
be hidden somewhere I guess (it is just property of layer). Moreover
it is sometimes buggy (see the screenshot).

Anyway it would be great to add transparency support to GRASS display
architecture (then it could be available from d.rast GUI form). (?)

Martin

[Michael Barton]

Can we wrap it into a properties dialog for d.* commands? (copying Daniel on
this).

Michael

Post by Martin Landa
Michael,

Post by Michael Barton
I did try that and here's why I went to a spinner.
I like sliders. But...the slider looks bad (doesn't format quite right) and
takes up a lot of room (at least on my Mac version) when used in a
customtreectrl.
I love contextual menus, but strongly resist putting something there that is
not also available elsewhere (i.e., with a left mouse click). To do
otherwise means that it is visually hidden and the user has to know that it
exists a priori in order to use that feature. To the best of my knowledge,
this is contrary to standard interface guidelines.
So this would mean putting an 'opacity' popup button somewhere--either in
the properties dialog or in the tree item line and then creating a text
object that would need to be updated dynamically every time the opacity
control is changed. I decided that a spinner was easier to implement than a
button and some kind of text that would need to be updated (always tricky).
It offers direct user access to the function. You can type or spin, it
offers direct user feedback to the state of opacity without any updating
code.

OK, on the other hand I feel wx.SpinCtrl in layer tree as a
"disturbing" feature. I think there is place only for 'layer name'
and checkbox (enable/disable). The widget for setting transparency can
be hidden somewhere I guess (it is just property of layer). Moreover
it is sometimes buggy (see the screenshot).
Anyway it would be great to add transparency support to GRASS display
architecture (then it could be available from d.rast GUI form). (?)
Martin

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

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

[Michael Barton]

Martin,

Post by Martin Landa
Michael,

Post by Michael Barton
I did try that and here's why I went to a spinner.
I like sliders. But...the slider looks bad (doesn't format quite right) and
takes up a lot of room (at least on my Mac version) when used in a
customtreectrl.
I love contextual menus, but strongly resist putting something there that is
not also available elsewhere (i.e., with a left mouse click). To do
otherwise means that it is visually hidden and the user has to know that it
exists a priori in order to use that feature. To the best of my knowledge,
this is contrary to standard interface guidelines.
So this would mean putting an 'opacity' popup button somewhere--either in
the properties dialog or in the tree item line and then creating a text
object that would need to be updated dynamically every time the opacity
control is changed. I decided that a spinner was easier to implement than a
button and some kind of text that would need to be updated (always tricky).
It offers direct user access to the function. You can type or spin, it
offers direct user feedback to the state of opacity without any updating
code.

OK, on the other hand I feel wx.SpinCtrl in layer tree as a
"disturbing" feature. I think there is place only for 'layer name'
and checkbox (enable/disable). The widget for setting transparency can
be hidden somewhere I guess (it is just property of layer). Moreover
it is sometimes buggy (see the screenshot).

The only controls I can find for interactively changing a variable in a
continuous manner are a spinctrl and a slider. So we are stuck with one or
the other.

I don't see where this is buggy. It might not look as aesthetically pleasing
because the spin control directly follow the text rather than being aligned
at the end. That may (or may not) be fixable. This would apply to any
control placed in the customtreectrl in this way.

While it would not take care of alignment, something that might be more
visually appealing would be a graphical button whose color changes from dark
green (or grey) to white in response to opacity settings. Clicking the
button could bring up a dialog with a slider. However, this would require
considerably more code than simply using a spinctrl in place of a graphical
button. Something to think about though.

Post by Martin Landa
Anyway it would be great to add transparency support to GRASS display
architecture (then it could be available from d.rast GUI form). (?)

We can simply add this to the form for any command that starts with d.*,
then it would be more like the situation in the current TclTk GUI.

Thinking of this brings us back to more wxPython-based control of rendering.
You mentioned creating a driver. I assume that you are thinking about using
wx.ImageFromStream for a direct wx image driver. Before launching into that,
it would probably be good to redo the compositing in wxPython and not use
g.pnmcomp. I suppose it's doable within wx.Image. This would make it easier
to switch from the PNG driver to a wx driver.

Michael




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

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

[Glynn Clements]

Post by Michael Barton

Post by Martin Landa
Anyway it would be great to add transparency support to GRASS display
architecture (then it could be available from d.rast GUI form). (?)

We can simply add this to the form for any command that starts with d.*,
then it would be more like the situation in the current TclTk GUI.

As the opacity applies to the way that that command's output is
composited, rather than affecting the command itself, it would make
more sense to base the decision on whether the command is associated
with a layer tree.

[Michael Barton]

Good point. Hadn't thought of it that way.

Michael

Post by Glynn Clements

Post by Michael Barton

Post by Martin Landa
Anyway it would be great to add transparency support to GRASS display
architecture (then it could be available from d.rast GUI form). (?)

We can simply add this to the form for any command that starts with d.*,
then it would be more like the situation in the current TclTk GUI.

As the opacity applies to the way that that command's output is
composited, rather than affecting the command itself, it would make
more sense to base the decision on whether the command is associated
with a layer tree.

__________________________________________
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