> Regarding the implementation, what I had in my own mind was that the
> main context menu should list the objects that have been clicked on
> (assuming there is more than one) plus anything else that is not
> object related (eg Redraw and Close).   The object-specific menu
> entries would then be sub-menus.   That allows you to switch quickly
> to a different object sub-menu if you mis-select, and also makes it
> clear which object you're working on before you make that final click.
>   Is there a reason why you didn't do that?


Yes absolutely.  This is the direction I started in and it was a dead
end.  There were several reasons that strategy would not work out, a
couple of which I list below.

The underlying function that shows the object menu is used in more
than one context, and it was like having a screwdriver with a hammer
attached on the end.  When you needed a screwdriver, you ended up
hitting yourself in the head with the hammer.

Another reason was that it was leading to a can of worms.

In the end Jean-Pierre and I had only one disagreement on the
implementation, and that was concering the right mouse click.  I had
coded it so that you first had to select and object with the left
mouse and during this processes saw the Selection Clarification menu.
 Then the right click menu would always operate on the previously
selected objec, and would give you the object specific behavior.  

He wanted the right click to give you the selection menu also.  I
still disagree with that UI, but yielded for now.

This was a lot of work, and I think it is a major win for the package
in terms of useability.   I have no reason to change it for now.


> 
> BTW, have you tried clicking on "Selection Clarification"?   It
> displays a menu, which I didn't expect.   Is that intended?


The selection clarification menu item does not even show under linux,
apparently due to a difference in wxWindows implementations.  So it
does not affect me.  It will probably get resolved by itself as
wxWindows evolves.



Reply via email to