[squeak-dev] Re: swapMouseButtons broken in trunk
David T. Lewis
lewis at mail.msen.com
Thu Mar 10 04:55:56 UTC 2016
On Mon, Mar 07, 2016 at 03:13:10PM -0800, marcel.taeumel wrote:
> It's actuallly really simple:
>
> term := #swapMouseButtonsChanged.
> senders := OrderedCollection new.
>
> SystemNavigation default allObjectsDo: [:ea |
> 1 to: ea class instSize do: [:i | |val|
> val := ea instVarAt: i.
> val isSymbol ifTrue: [
> val = term ifTrue: [senders add: ea]]]].
>
> senders explore.
>
> On my laptop, it benches to '11.6 per second. 85.9 milliseconds per run.'
>
> Should we add this to trunk? We could filter out method additions or method
> references to produce cleaner results. The "Senders" shortcut might just
> spawn an additional explorer with the resulting objects. Fairly easy.
>
> Best,
> Marcel
>
I do like this idea. But just to keep in in context, I want to remind us of
the original problem that we were trying to address.
IIRC, the original problem was that we had a preference with a #changeSelector
that had been initialized to something other than the default pattern of
#somethingChanged. Specifically, for that particular preference, the selector
was #installMouseDecodeTable rather than #swapMouseButtonsChanged.
So later on, someone made some improvements to the preferences mechanism
that somehow caused that preference to be re-initualized, so that its
#changeSelector was now the default selector #swapMouseButtonsChanged.
That did not work because there had never been an implementation of
EventSensor>>swapMouseButtonsChanged.
Marcel figured this out and added the missing implementation:
EventSensor>>swapMouseButtonsChanged
self installMouseDecodeTable.
So at this point, we know of exactly one preference that caused a problem
because the historical #changeSelector did not match the default pattern.
Are there other preference that would lead to the same kind of confusion?
After adding an accessor for #changeSelector, I find that in my image:
((Preference allSubInstances select: [ :e | ( e changeSelector notNil
and: [ ( '*Changed' match: e changeSelector ) not ] )
and: [ #value ~= e changeSelector ] ] )
collect: [:e | e changeSelector] ) asSet asArray.
==> #(#serviceUpdate #doAutomaticLayoutOfFlapsIfAppropriate #universalTilesSettingToggled #changesInPreferences #classicTilesSettingToggled)
So without looking into the details, I would say that there are maybe five
of these selectors that could possibly cause a problem. If one or more of
them is a concern, then I would expect that the missing #somethingChanged.
implementation could be provided, exactly as was done for
EventSensor>>swapMouseButtonsChanged.
Looking to the future, I would expect that as new preferences are added,
they would naturally follow the convention of using #somethingChanged as
the changed selector.
So do we need to engineer a solution to this problem? Maybe not. It might
be better to just find any existing preferences that might still have a
problem, fix them, and move forward with the assumption that any new
preferences will follow the established #somethingChanged convention.
Dave
More information about the Squeak-dev
mailing list
|