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...
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
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 *
Michael Barton wrote:
> 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.
It's generally considered good practice to have menus which don't
change according to context. Instead, the menu always has the same set
of options, but those which cannot be used in a given context are
insensitive. Also, entries which lead to a submenu are never
insensitive, only leaf entries. This way, the user can always see the
entire set of menu options.
It has also been suggested that there should be a simple way to
discover *why* a menu option is greyed out, either via its tooltip or
by displaying an information dialog if a greyed-out entry is chosen.
However, implementing this is easier in some toolkits than others.
--
Glynn Clements <glynn@gclements.plus.com>