On Thu, Jul 31, 2014 at 5:38 AM, Chris Muller asqueaker@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