[squeak-dev] generalizedYellowButtonMenu

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

> 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 <[hidden email]> 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
>>
>>
>
>

> 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 <[hidden email]> 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
>>>
>>>
>>
>>
>
>
>

> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>
>>>>
>>>
>>
>>
>
>

> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>
>>>>
>>>
>>>
>>
>>
>>
>

> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>
>>>>>
>>>>
>>>
>>>
>
>