[GRASS-dev] Re: wxGUI: edit button

[Michael Barton]

On Aug 2, 2008, at 3:31 PM, Martin Landa wrote:

> Michael,
>
> I am just checking out r32469. Thanks for the fixes!
>
> What I don't like so much is 'edit' button, I don't see any reason for
> that button, it just simulates right-click -- pop-up menu. Also dialog
> for changing opacity is not necessary in my eyes - switching from text
> to spin mode seems to me being better. Just subjective point of
> view...

Right-click contextual menus are fine and very handy. However, widely  
accepted interface standards call for also exposing functions in  
contextual menus visually in some way--in a menu, button, or other  
control--for several reasons. Right-click functions are visually  
hidden. To 'discover' them, a users needs to click all over an  
interface to see what parts respond and what parts do not. And some  
users might not know to even try this trick--leading to considerable  
frustration. Although most mouses have at least 2 buttons these days,  
not all laptops have dual buttons--and no Mac laptop has dual buttons.  
Of course you can simulate a right-click with 2 hands (holding down a  
modifier key), but you should be able to access a function with one  
hand. This is equally important for manually impaired users.  
Conceptually, a GUI should avoid functions for which there is no  
visual clue to their existence--though non-visual shortcuts also can  
be available (e.g., right-click contextual menus and hot keys).

Adding the button solves several other annoying bugs. I can turn off  
the tree style to allow for direct item name editing. This would  
regularly pop up an editing text box when it wasn't wanted--and  
sometimes was very difficult to get rid of. Also, the spin control for  
opacity looked kind of clunky, as you pointed out a long time ago  
(which got me thinking about better ways to do this).

This puts all the layer modification functions in one easily  
accessible place--your nice menu. The right click is still functional  
for those who prefer that short-cut as is double-clicking to access  
the properties dialog (and the rename box no longer pops up by  
accident).

A couple of ideas to run by you. Do you think users would like to see  
the opacity level in the layer text? Or is it sufficient to pop up the  
opacity dialog. It's easy enough to add "nnn% opacity" to each layer  
name, but it makes it that much longer. Also, I could do an icon  
button instead of the text "Edit...". I might try one and see which  
looks better.

One problem with using the treemixin.DragAndDrop. If you are not  
dropping onto a layer (i.e., above or below the tree), nothing is  
passed to the OnDrop method. Normally, this is no problem. But if you  
create a group, it is possible to get into a situation where you  
cannot create anything outside the group. I've made a work around, but  
it is not obvious. If you select a group that is closed (i.e., not  
expanded) and click to add a layer, it will behave like a non-group  
layer and the new layer will be inserted above the group. However, it  
you select a group that is expanded and click to add a layer, the new  
layer will go into the group. I'm not happy with a non-obvious  
solution to this, but can't think of a better solution. Maybe you can  
come up with something. Currently, the rules are:

1) add a layer and no other layer is selected (normally only happens  
when you start to build the layer tree): new layer is prepended to the  
top of the tree.
2) add a layer and a map/command layer is selected (i.e., not a group  
but it could be IN a group): new layer is inserted directly above the  
selected layer
3) add a layer and a group is selected and the group is NOT expanded:  
new layer is inserted directly above the selected group
4) add a layer and a group is selected and the group IS expanded: new  
layer is prepended to the top of the group's children
5) drag and drop a layer on top of another map/command layer (i.e, not  
on a group but it could be IN a group): new layer is inserted directly  
above the selected layer
6) drag and drop a layer on top of a group: new layer is prepended to  
the top of the group's children
7) drag and drop a layer outside the tree (i.e, not on any existing  
layer): layer is not moved.

Finally, there have been some lack of robustness with the interaction  
of drag-and-drop and rendering. I don't know if they are fixed or not  
yet as I haven't had enough time to do attempt to break this. I hope  
with your changes and with mine, we've solved these, but I'll try it  
out some more. One problem that still remains is that 2 rasters no  
longer overlay so that the bottom one shows through the nulls. I don't  
know if this is an issue with the new preferences or with something in  
the rendering. I'll try to follow this up as I test this.

Cheers
Michael

>
>
> Martin
>
> -- 
> Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/ 
> ~landa *