On Fri, May 10, 2013 at 09:38:28AM -0400, Bob Arning wrote:
> Maybe, but what's happening here is in MenuItemMorph:
> 
> mouseDown: evt
>     "Handle a mouse down event. Menu items get activated when the mouse 
> is over them."
> 
>     evt shiftPressed ifTrue: [ ^super mouseDown: evt ].  "enable label 
> editing"
>     evt hand newMouseFocus: owner. "Redirect to menu for valid transitions"
>     owner selectItem: self event: evt
> 
> I see this code as far back as squeak 3.2 with a 10/10/2000 date and 
> Andreas's initials. If you comment out the first line, you get the 
> behavior David was looking for. It would be interesting to know who 
> might be using this feature.
> 
> Cheers,
> Bob

Aha! I suspect that no one is using that feature at all.

But just commenting it out is not sufficient, because in Morphic the shift
state should come from the input event, not from a direct reference to
Sensor, which is what ends up getting done in #browseMethodsWithSourceString:
later on.

I also tried changing the menu selections to have separate selectors for
case-sensitive and non-case-sensitive versions of the search, and this
works fine. However, I'm not happy with that approach because it will
lead to a cluttered menu if we apply the approach consistently to the
various searches for "source with it", "comments with it", etc. 

There is a conflict between the Morphic use of the shift key for selection
of morphs, versus the earlier convention (maybe just in MVC) of having
the shift state control case sensitive search for a variety of menu
selections. I am inclined to think that the earlier convention is more
important in this case, and that is reasonable for Morphic menu items to
pass shift state to the menu selections rather than use it directly to
support editing menu options.

Having said that, I do not think it would be good to make the change
to MenuItemMorph>>mouseDown: until the direct reference to Sensor in
#browseMethodsWithSourceString: can also be eliminated, so I will not
change anything in trunk right now.

Dave


> 
> On 5/10/13 7:23 AM, karl ramberg wrote:
> >Morphic has shift+left-click drag selection of morphs.
> >
> >Karl
> >
> >
> >On Fri, May 10, 2013 at 1:00 PM, Bob Arning <arning315 at comcast.net 
> ><mailto:arning315 at comcast.net>> wrote:
> >
> >    It would be nice if the shift key worked as it once did and I
> >    don't know what the "new" shift-key-in-menu paradigm is or whether
> >    it could be plausibly reverted. However, it does seem useful if
> >    the menu could give some indication of when there were two
> >    possibilities for one menu item and which is going to happen if
> >    you click now. Not everyone has that memorized.
> >
> >    Cheers,
> >    Bob
> >
> >    On 5/9/13 9:35 PM, David T. Lewis wrote:
> >>    On Thu, May 09, 2013 at 08:52:45AM -0400, Bob Arning wrote:
> >>>    On 5/9/13 8:21 AM, David T. Lewis wrote:
> >>>>    So maybe some other mechanism is better, such as a separate menu 
> >>>>    entry?
> >>>    sounds good
> >>>
> >>    I've looked at this a bit more, and there are several other menu 
> >>    items for
> >>    which case-sensitive matching is controlled by the shift key. I 
> >>    suspect that
> >>    the original user interface concept here is that the shift key (which 
> >>    one
> >>    might think of as the "upper case key") controls whether a menu 
> >>    selection
> >>    should pay attention to case. For someone familiar with the keyboard 
> >>    shortcuts,
> >>    this would be very efficient and easy to remember.
> >>
> >>    This mechanism does not work in Morphic because the shift key is used 
> >>    for
> >>    other purposes. So the original concept of controlling case-sensitive 
> >>    searches
> >>    based on state of the shift key still exists and it still works in 
> >>    MVC, but
> >>    it has not been translated into something that works for Morphic.
> >>
> >>    I'm not sure that changing this for "method source with it" is a good 
> >>    idea
> >>    unless that same approach can be applied consistently for "method 
> >>    strings
> >>    with it", "class comments with it", etc. So I'm still thinking about 
> >>    it...
> >>
> >>    Dave
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
> 

>