Chris Muller 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

Ah, I see. Yes this would be confusing (and is the case I was referring 
to). Plus I was looking at this code again and it does "feel" wrong to 
me. I think the idea of the generalized yellow button menu is to act 
similarly to how dragging morphs works - an activity not wired into each 
morph directly, but rather provided by the world as the default action 
for morphs not specifying what the behavior of mouse actions is. The 
same should be true for the context menu, meaning that it should be an 
action provided by the world for yellowButtonClicks on submorphs instead 
of being wired into each morph separately. What do other people think?

(I actually think that changing this would be pretty straightforward)

Cheers,
   - Andreas

> 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
>>>>
>>>>
>>>
>>
>>
> 
>