swapMouseButtons broken in trunk

May we please evaluate that from Inbox for a couple of weeks before
putting that into trunk?

We've added a new language feature being used for almost nothing but
Preferences, now we want to loosen the definition of Smalltalk
"senders" for them too?

I admit, your idea sounds interesting -- I, myself, pretty much only
instantiate Symbols which are also method selectors.

However, I think when we feel the need to change our tools
for something that should be dead simple, maybe its the design trying to
speak to us.  Maybe its a good time to ask, "why are we
doing this?  is there a simpler way?"

What I still don't understand is why we can't see the Preference's
'changeSelector' getting set to the value, #swapMouseButtonsChanged
anywhere?  Should't the initial instantiation of the Preference object
require that as a parameter, and so then it should show up in senders,
and it would make sense how it worked..??  :(

On Mon, Mar 7, 2016 at 5:13 PM, marcel.taeumel <[hidden email]> wrote:

> we might want to provide symbol search through objects. This particular
> symbol is hold in a preference instance in the instVar changeSelector.

Symbol search through objects may also be useful to find the selectors
only used in MessageSends.

In my code I use them all other the place (menus, buttons, pluggable
behaviors) mostly in the form of LambdaMessageSend
(http://www.zogotounga.net/comp/squeak/functionaltalk.htm).


Stef

Hi David,

I think that any object is able to send #perform: based on some (other object's) state. From time to time, this is a convenient pattern. For example, take the Tool Builder resp. Pluggable Widgets approach. Many callbacks are stored in instances of Pluggable*Morph.

If we want to expand senders search to the object level, we should respect all kinds of objects. A blacklist to rule out some false-positives, but no whitelist. 82ms is fast enough for invoking the senders search. Like "thorough senders", this should become a preference because we would need to spawn 2 windows in that case: one senders browser and one object explorer.

Best,
Marcel

I don't think it would help with the preferences that we are discussing
here, but as an aside I'll note that the "self flag: aSelector" hack is
another way to make hidden senders visible. See for example
Project>>#dispatchTo:addPrefixAndSend:withArguments: which uses this to
prevent methods like #mvcStartUpLeftFlush and #morphicStartUpLeftFlush
from appearing to be unsent messages.

Dave

Hi David,

you have a point there. However, this requires discipline. I am thinking about better tool support for code that might lack this kind of code-centered architecture. The Squeak image is full of objects and only part of it are code artifacts classes or methods. In the spirit of DataStream (ReferenceStream), serialized project files, or the *.image file itself, we need tools for working with objects that are not code.

Best,
Marcel

I agree. The "self flag" hack works in the case of the method dispatcher
for Project because new methods will rarely be added, and then only by a
small number of people who would already be familiar with the mechanism.
But expecting it to work in a more general case is not realistic.

Besides, if we had a disciplined process for managing preferences, we
would not have all those preferences in the first place ;-)

Dave

> If we want to expand senders search to the object level, we should respect
> all kinds of objects. A blacklist to rule out some false-positives, but no
> whitelist. 82ms is fast enough for invoking the senders search. Like
> "thorough senders", this should become a preference because we would need to
> spawn 2 windows in that case: one senders browser and one object explorer.

Marcel, the "references" search is for what you refer to, not "senders".

When I'm making a MessageTrace, which is interacting with a single
window, the last thing I want is for it to be popping up "Explorer"
windows on every invocations of senders.

Plus, what about the imbalance implementors?  Senders means one thing,
implementors means another?  No, the what we really want here is to
put this on References.

For senders, what David said with #flag: is the right solution, the
solution I was referencing from my original post in this thread:.

Hi Chris,

what is the "references search"? Do you mean the message finder?

Best,
Marcel

Maybe we can add it to this list of operations:



Best,
Marcel

> what is the "references search"? Do you mean the message finder?

No, I'm referring to the function shown in your references-1.png
picture just above the red box.  Also invoked by Shift+Command+N.  For
when you browse references to a Class.

Invoking that function on a Symbol expression now appears to do
nothing.  So this would be a good place to fit your new feature into
the IDE.  It actually is finding and presenting references to the
Symbbol, so "References" fits very well.

I still strongly recommend use of the #flag: approach, however,
whereever "magic" implentations breaks message tracing.

On Mon, Mar 07, 2016 at 03:13:10PM -0800, marcel.taeumel wrote:
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

On 3/10/16, Chris Muller <[hidden email]> wrote:
+1

>
> I still strongly recommend use of the #flag: approach, however,
> whereever "magic" implentations breaks message tracing.
>
>