[squeak-dev] Re: generalizedYellowButtonMenu

Chris Muller asqueaker at gmail.com
Wed Jan 13 22:02:02 UTC 2010


Oh shoot, I have once again encountered the scenario where it looks
impossible to handle the yellow button without customizing Morphic's
dispatch behavior.  My memory of the original problem has been
revived!

In my prior response (from months ago, below), I thought everything
was fine because my example was too simple.  A Morphic programmer can
respond to the yellow button for MyMorph in a simple composition:

  aMyMorph(123)
    aRectangleMorph(456)

The problem scenario arises with a deeper containership of Morphs like:

  aMyMorph(123)
    aMyMorph(456)
      aRectangleMorph(789)

(for simplicity of discussion, each Morphs bounds is completely
contained within its owner, but with some owner's bounds exposed,
allowing click on any Morph of the tree)

I want the *inner-most* MyMorph, aMyMorph(456), to be able to handle
the yellow-button, even when I right-click within the bounds of
aRectangleMorph(789).  The dispatcher ensures aRectangleMorph(789)
gets #mouseDown: first, which calls #yellowButtonActivity: which is
fine.  However, yellowButtonActivity gives the *outermost* owner first
crack at it.  Since I also want the outer morph (aMyMorph(123)) also
has its own yellow-button-activity, but only when clicked on directly,
*outside* the bounds of aMyMorph(456).  Unfortunately, the
RectangleMorph is playing leap-frog and so I am getting the
aMyMorph(123)'s behavior even though the Event's point is within
aMyMorph(456).  This seems wrong.

The only solution seems to, once again, revert Morph>>#mouseDown: back
to the 3.8 version (without the yellow-button check) or override
Morph>>#processEvent:using: with my own dispatching behavior.  That
method warns that overriding it is a "powerful hook".

Is this really what's necessary just for aMyMorph(456) to be able to
respond to the yellow button?

 - Chris


On Thu, Sep 10, 2009 at 12:19 PM, Chris Muller <asqueaker at gmail.com> wrote:
> I was afraid you were going to ask that.  But forcing me to work
> through it _one more time_ has apparently yielded the need for me to
> eat my words and apologize!
>
> I suppose the overall root cause of my problem/confusion is that there
> are multiple ways, at least semantically, to express in your Morphic
> code that you want to handle the yellow button.  In my case,
> MyCustomMorph has a couple of RectangleMorphs in its sub-tree that
> exist solely for rendering purposes.  I want all of their #mouseDown
> events to just be handled by aCustomMorph owner.
>
> So, at some point a long time ago, I put somewhere in my init code:
>
>  someChildRectangleMorph on: #mouseDown send: #mouseDown: to:
> theOwningCustomMorph
>
> The exercise today has reminded me this is unnecessary given the
> nature of the eventDispatcher which offers everyone in the tree a
> chance to handle.  But I think this old #on:send:to: code has managed
> escape my critical eye ever since because.. it didn't "look wrong" (at
> least semantically), even though it is when you consider the details
> of event-dispatach.  So, apparently I was wrong, I'm sorry.
>
> So, to enumerate something positive, here are the definitive steps
> needed to handle the yellow button in a CustomMorph subclass:
>
>  - Turn off global Preference #generalizedYellowButtonMenu
>  - Implement #wantsYellowButtonMenu  ^ true  in the CustomMorph subclass.
>  - Override #mouseDown: in the CustomMorph subclass (do not call
> super mouseDown:).
>
>  - Chris
>
>
> On Wed, Sep 9, 2009 at 9:24 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
>> Chris Muller wrote:
>>>
>>> Hi, I've had the exact same problem ever since 3.9.  The problem
>>> manifests if you want to handle the yellow button in MyCustomMorph,
>>> when it is embedded in a standard Morph, such as RectangleMorph.
>>
>> Can either you or Elöd describe what the actual problem is you are seeing?
>> You both say that there is "some" problem but you don't describe it terms of
>> expected vs. observed behavior. The problem isn't obvious to me, for example
>> when I embed a TextMorph into a RectangleMorph the behavior is just what I
>> would expect (i.e., the text menu in the text morph and the generalized
>> context menu in the rectangle morph).
>>
>> One possible issue that I can see with the code is that it would not work
>> with a custom event handler, i.e.,
>>
>> m := Morph new.
>> m on: #mouseDown send: #value: to:[:evt| evt yellowButtonPressed
>> ifTrue:[...]].
>>
>> Is this the problem you are describing? If so I'm not sure why you say you
>> can't fix the issue in your custom Morph subclass since it's trivial to just
>> reimplement mouseDown: to not do that.
>>
>> Cheers,
>>  - Andreas
>>
>>> For Maui, I tried so hard to find a solution that would allow
>>> MyCustomMorph to intercept and respond to the yellow button with my
>>> own handler, that would not require a change to core 3.9 Squeak code.
>>>
>>> I was unsuccessful.  To do the above, I had to revert:
>>>
>>>  Morph>>#mouseDown:
>>>
>>> to the version from 3.8.  Specifically, you may simply delete these
>>> lines that were erroneously added in 3.9:
>>>
>>>        evt yellowButtonPressed
>>>                ifTrue: ["First check for option (menu) click"
>>>                        ^ self yellowButtonActivity: evt shiftPressed].
>>>
>>> but be sure to _keep_ these original lines from 3.8, of course:
>>>
>>>        self eventHandler
>>>                ifNotNil: [self eventHandler mouseDown: evt fromMorph:
>>> self]
>>>
>>> This, btw, also restores the correctness of the methods *comment*,
>>> which also became wrong when the 3.9 change was introduced.
>>>
>>> I have been running with this fix in my 3.9 image for 2 years with no
>>> ill-side-effects, but with proper eventHandling for the yellow button
>>> (not to mention cleaner code).
>>>
>>> Cheers,
>>>  Chris
>>>
>>>
>>> On Tue, Sep 8, 2009 at 10:57 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
>>>>
>>>> Elöd Kironský wrote:
>>>>>
>>>>> Can someone please explain what is the preference
>>>>> "generalizedYellowButtonMenu" for? It is by default enabled in Squeak
>>>>> and it
>>>>> breaks the yellowButtonPressed event in mouseDown: methods. I've tried
>>>>> to
>>>>> Google it, but the only thing I found, that it makes problems in other
>>>>> packages too. Am I missing something? This was introduced somewhere in
>>>>> 3.9 I
>>>>> think, but I'm not sure where and why. Does someone know? Thanks in
>>>>> advance,
>>>>
>>>> It enables the use of context (yellow button) menus on arbitrary Morphs.
>>>> I'm
>>>> not sure what you mean by "it breaks the yellowButtonPressed event in
>>>> mouseDown: methods" though. Do you have a more specific description of
>>>> the
>>>> problems you are encountering?
>>>>
>>>> Cheers,
>>>>  - Andreas
>>>>
>>>>
>>>
>>>
>>
>>
>>
>



More information about the Squeak-dev mailing list