Hi!
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,
Elod
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
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.
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@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
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@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
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@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@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
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@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@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
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@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@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@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
On Thursday 14 January 2010 03:32:02 am Chris Muller wrote:
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).
Mouse events are delivered to a morph whose containsPoint: method returns true. By default, a morph returns true if cursor position is within its bounds. If you are dealing with special situations, create a class and override this method to handle the special conditions.
Also see containsPoint:event: and dispatchMouseDown:with: methods.
You could also have morphs delegate selected events to other morphs. See on:send:to: for details.
HTH .. Subbu
Do you by any chance have a test case for this? I'm not entirely sure what's wrong with what you describe. One thing you could try is to #lock the RectangleMorph - this should make it completely ignore any clicks.
Cheers, - Andreas
Chris Muller wrote:
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@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@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@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
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Chris Muller -
Elöd Kironský -
K. K. Subramaniam