[squeak-dev] The Trunk: Tools-eem.526.mcz

Chris Muller ma.chris.m at gmail.com
Thu Jul 31 19:35:08 UTC 2014


> On Thu, Jul 31, 2014 at 5:38 AM, Chris Muller <asqueaker at gmail.com> wrote:
>>
>> Introducing new dependencies on Sensor is bad practice.  We should stick
>> to the event mechanism.
>
> No shit.

Hey man, you toss in a new Sensor shiftPressed you gotta expect a
LITTLE flak.  ;-)

> But events are not passed throguh to dispatched menu picks AFAICT.
> If there's a way to get the event that resulted in the menu pick I'm all
> ears.

MenuItemMorph>>#mouseUp: calls its #invokeWithEvent:, which checks the
number of args of the handler method.  So, yes!  It appears so!  Just
add the arg..?

Oops, but, the problem is in MenuItemMorph>>#mouseDown:.  It usurps
the Shift key so the user can "edit" the menu choices.  Man, oh man,
what a useless waste of such a powerful toggle-gesture otherwise
available to all menu items!  We should talk about reclaiming that..!

>> I'm not sure what you're trying to do, but did you know we already have
>> AlternatePluggableListMorphOfMany which implements extending selection via
>> Shift key..?
>
> The ChangeList doesn't work that way.  It has its own internal boolean array
> of selected elements.  In any case this is about computing a set of
> selections, not toggling a single selection.  The point being that computing
> a set of selections can either select that set, or add that set to the
> existing set of selections.

I see and understand what you're doing and why.  Another solution
could be to make your shifted behavior the default for all the
"select" menu options.  The menu already provides deselect all so the
user could do that and then "build up" their selection along multiple
criteria.  That way the whole menu's power is built up without having
to check for shiftPressed in all those places.

Hey, I saw the new Sensor use and so just trying to bounce some ideas around.

 - Chris


More information about the Squeak-dev mailing list