Smalltalk › Squeak › Squeak - Dev

Morph wants to know when it loses focus

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

18 messages Options

timrowledge

Morph wants to know when it loses focus

I must be missing something obvious but searching around focus and lose and so on hasn’t revealed anything to me so far; I want to know when my Morph has lost mouse focus. I need something like when a halo goes away if you click outside it. I know this is going to reveal an embarrassing inability to read something right on front of me but at some point you just have to ask where your spectacles are even if they usually turn out to be on your head.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computers are useless. They can only give you answers.

tty

Re: Morph wants to know when it loses focus

I don't know, but since I am wrestling Morphic Events I am in the neighborhood and some things look like they may help.

HandMorph>>releaseMouseFocus ?

SystemWindow >>mouseUp?

From what I see, basically everything about MorphicEvents originates in HandMorph. Take a look at HandMorph>>add/removeMouseListener as well.

cordially,

tty.

---- On Tue, 11 Feb 2014 12:28:30 -0800 tim Rowledge<[hidden email]> wrote ----

I must be missing something obvious but searching around focus and lose and so on hasn’t revealed anything to me so far; I want to know when my Morph has lost mouse focus. I need something like when a halo goes away if you click outside it. I know this is going to reveal an embarrassing inability to read something right on front of me but at some point you just have to ask where your spectacles are even if they usually turn out to be on your head.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computers are useless. They can only give you answers.

Bert Freudenberg

Re: Morph wants to know when it loses focus

In reply to this post by timrowledge

On 11.02.2014, at 21:28, tim Rowledge <[hidden email]> wrote:

> I must be missing something obvious but searching around focus and lose and so on hasn’t revealed anything to me so far; I want to know when my Morph has lost mouse focus. I need something like when a halo goes away if you click outside it. I know this is going to reveal an embarrassing inability to read something right on front of me but at some point you just have to ask where your spectacles are even if they usually turn out to be on your head.

Your morph should be sent keyboardFocusChange: false when it loses focus.

- Bert -

smime.p7s (5K) Download Attachment

timrowledge

Re: Morph wants to know when it loses focus

On 11-02-2014, at 12:50 PM, Bert Freudenberg <[hidden email]> wrote:

> On 11.02.2014, at 21:28, tim Rowledge <[hidden email]> wrote:
>
>> I must be missing something obvious but searching around focus and lose and so on hasn’t revealed anything to me so far; I want to know when my Morph has lost mouse focus. I need something like when a halo goes away if you click outside it. I know this is going to reveal an embarrassing inability to read something right on front of me but at some point you just have to ask where your spectacles are even if they usually turn out to be on your head.
>
> Your morph should be sent keyboardFocusChange: false when it loses focus.

Unfortunately that is only for something that got keyboard focus. I thought that newMouseFocus: ought to be it but despite comments claiming to release the mouse focus it only seems to be internal to the HandMorph; nothing seems to go to the old focus morph.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
This is all a lot simpler and a lot more complicated than you could possibly imagine

Bert Freudenberg

Re: Morph wants to know when it loses focus

On 11.02.2014, at 22:21, tim Rowledge <[hidden email]> wrote:

>
> On 11-02-2014, at 12:50 PM, Bert Freudenberg <[hidden email]> wrote:
>
>> On 11.02.2014, at 21:28, tim Rowledge <[hidden email]> wrote:
>>
>>> I must be missing something obvious but searching around focus and lose and so on hasn’t revealed anything to me so far; I want to know when my Morph has lost mouse focus. I need something like when a halo goes away if you click outside it. I know this is going to reveal an embarrassing inability to read something right on front of me but at some point you just have to ask where your spectacles are even if they usually turn out to be on your head.
>>
>> Your morph should be sent keyboardFocusChange: false when it loses focus.
>
> Unfortunately that is only for something that got keyboard focus. I thought that newMouseFocus: ought to be it but despite comments claiming to release the mouse focus it only seems to be internal to the HandMorph; nothing seems to go to the old focus morph.

Yep.

- Bert -

smime.p7s (5K) Download Attachment

Jecel Assumpcao Jr

Re: Morph wants to know when it loses focus

Bert Freudenberg wrote:

> On 11.02.2014, at 22:21, Tim Rowledge wrote:
> > On 11-02-2014, at 12:50 PM, Bert Freudenberg wrote:
> >> Your morph should be sent keyboardFocusChange: false when it loses focus.
> >
> > Unfortunately that is only for something that got keyboard focus. I thought that
> > newMouseFocus: ought to be it but despite comments claiming to release the
> > mouse focus it only seems to be internal to the HandMorph; nothing seems to
> > go to the old focus morph.
>
> Yep.

So would having the morph return true to #handlesMouseOver: enough to
make it receive #mouseLeave: events? We really need some kind of event
debugger to see what is going on because there are too many interacting
parts. Sort of like what Linux has become (just try to figure out how to
select whether to boot in text or graphical modes, for example).

-- Jecel

timrowledge

Re: Morph wants to know when it loses focus

In reply to this post by Bert Freudenberg

On 11-02-2014, at 1:51 PM, Bert Freudenberg <[hidden email]> wrote:

>
> On 11.02.2014, at 22:21, tim Rowledge <[hidden email]> wrote:
>
>>
>> On 11-02-2014, at 12:50 PM, Bert Freudenberg <[hidden email]> wrote:
>>
>>> On 11.02.2014, at 21:28, tim Rowledge <[hidden email]> wrote:
>>>
>>>> I must be missing something obvious but searching around focus and lose and so on hasn’t revealed anything to me so far; I want to know when my Morph has lost mouse focus. I need something like when a halo goes away if you click outside it. I know this is going to reveal an embarrassing inability to read something right on front of me but at some point you just have to ask where your spectacles are even if they usually turn out to be on your head.
>>>
>>> Your morph should be sent keyboardFocusChange: false when it loses focus.
>>
>> Unfortunately that is only for something that got keyboard focus. I thought that newMouseFocus: ought to be it but despite comments claiming to release the mouse focus it only seems to be internal to the HandMorph; nothing seems to go to the old focus morph.
>
> Yep.

Does anyone have any thoughts on why this doesn’t happen? Was it simply forgotten about, or found to be problematical and so removed? Seems like a useful thing to happen to me; but I’m not expert in Morphic.

As a work-around for now I’m over-riding #rejectsEvent: to test for a mouse down outside my bounds and killing the morph that way. Oh, and returning true since it seems likely a non-existent morph means its ghost rejects any events...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BFM: Branch on Full Moon

timrowledge

Re: Morph wants to know when it loses focus

In reply to this post by Bert Freudenberg

On 11-02-2014, at 4:45 PM, Jecel Assumpcao Jr. <[hidden email]> wrote:

> Bert Freudenberg wrote:
>> On 11.02.2014, at 22:21, Tim Rowledge wrote:
>>> On 11-02-2014, at 12:50 PM, Bert Freudenberg wrote:
>>>> Your morph should be sent keyboardFocusChange: false when it loses focus.
>>>
>>> Unfortunately that is only for something that got keyboard focus. I thought that
>>> newMouseFocus: ought to be it but despite comments claiming to release the
>>> mouse focus it only seems to be internal to the HandMorph; nothing seems to
>>> go to the old focus morph.
>>
>> Yep.
>
> So would having the morph return true to #handlesMouseOver: enough to
> make it receive #mouseLeave: events? We really need some kind of event
> debugger to see what is going on because there are too many interacting
> parts.

Tried that; it is sent too late in the process to catch what I need. For my needs here mouseLeave isn’t appropriate since you want to be able to enter and leave the morph and even mouseDown on it in order to do something like a HaloMorph does. It’s only if you mouseDown on some other morph that I want it to go away.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Real Daleks don't climb stairs - they level the building. <Re-no-vaaate><Re-no-vaaate!>

Bert Freudenberg

Re: Morph wants to know when it loses focus

In reply to this post by timrowledge

On 12.02.2014, at 00:48, tim Rowledge <[hidden email]> wrote:

> On 11-02-2014, at 1:51 PM, Bert Freudenberg <[hidden email]> wrote:
>
>> On 11.02.2014, at 22:21, tim Rowledge <[hidden email]> wrote:
>>
>>> On 11-02-2014, at 12:50 PM, Bert Freudenberg <[hidden email]> wrote:
>>>
>>>> On 11.02.2014, at 21:28, tim Rowledge <[hidden email]> wrote:
>>>>
>>>>> I must be missing something obvious but searching around focus and lose and so on hasn’t revealed anything to me so far; I want to know when my Morph has lost mouse focus. I need something like when a halo goes away if you click outside it. I know this is going to reveal an embarrassing inability to read something right on front of me but at some point you just have to ask where your spectacles are even if they usually turn out to be on your head.
>>>>
>>>> Your morph should be sent keyboardFocusChange: false when it loses focus.
>>>
>>> Unfortunately that is only for something that got keyboard focus. I thought that newMouseFocus: ought to be it but despite comments claiming to release the mouse focus it only seems to be internal to the HandMorph; nothing seems to go to the old focus morph.
>>
>> Yep.
>
> Does anyone have any thoughts on why this doesn’t happen? Was it simply forgotten about, or found to be problematical and so removed? Seems like a useful thing to happen to me; but I’m not expert in Morphic.
>
> As a work-around for now I’m over-riding #rejectsEvent: to test for a mouse down outside my bounds and killing the morph that way. Oh, and returning true since it seems likely a non-existent morph means its ghost rejects any events...

I guess the need doesn't arise often enough for it to have been added as a general feature. The only morph I'm aware of doing something similar would be a menu, which closes when you click outside. But that is sort-of modal so not exactly the same thing either. Or maybe it is?

- Bert -

smime.p7s (5K) Download Attachment

Chris Muller-3

Re: Morph wants to know when it loses focus

In reply to this post by timrowledge

Keep track of your morphs.

In Maui, you can have multiple views of the same identical object on
the screen at once. Whenever you hover any one of them, all views of
that same object on the screen are highlighted. When the mouse stops
hovering over it, all views are unhighlighted.

I accomplished this by having a MauiWorld with a collection of
'players' in that world.

Not sure if this is analogous to your need, but it works.

On Tue, Feb 11, 2014 at 5:55 PM, tim Rowledge <[hidden email]> wrote:

>
> On 11-02-2014, at 4:45 PM, Jecel Assumpcao Jr. <[hidden email]> wrote:
>
>> Bert Freudenberg wrote:
>>> On 11.02.2014, at 22:21, Tim Rowledge wrote:
>>>> On 11-02-2014, at 12:50 PM, Bert Freudenberg wrote:
>>>>> Your morph should be sent keyboardFocusChange: false when it loses focus.
>>>>
>>>> Unfortunately that is only for something that got keyboard focus. I thought that
>>>> newMouseFocus: ought to be it but despite comments claiming to release the
>>>> mouse focus it only seems to be internal to the HandMorph; nothing seems to
>>>> go to the old focus morph.
>>>
>>> Yep.
>>
>> So would having the morph return true to #handlesMouseOver: enough to
>> make it receive #mouseLeave: events? We really need some kind of event
>> debugger to see what is going on because there are too many interacting
>> parts.
>
> Tried that; it is sent too late in the process to catch what I need. For my needs here mouseLeave isn’t appropriate since you want to be able to enter and leave the morph and even mouseDown on it in order to do something like a HaloMorph does. It’s only if you mouseDown on some other morph that I want it to go away.
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Real Daleks don't climb stairs - they level the building. <Re-no-vaaate><Re-no-vaaate!>
>
>
>

Karl Ramberg

Re: Morph wants to know when it loses focus

In reply to this post by timrowledge

PasteUpMorph>>mouseDown: is where the world deletes halos.

Cheers,

Karl

On Tue, Feb 11, 2014 at 9:28 PM, tim Rowledge <[hidden email]> wrote:

I must be missing something obvious but searching around focus and lose and so on hasn’t revealed anything to me so far; I want to know when my Morph has lost mouse focus. I need something like when a halo goes away if you click outside it. I know this is going to reveal an embarrassing inability to read something right on front of me but at some point you just have to ask where your spectacles are even if they usually turn out to be on your head.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computers are useless. They can only give you answers.

timrowledge

Re: Morph wants to know when it loses focus

In reply to this post by Chris Muller-3

On 12-02-2014, at 8:18 AM, Chris Muller <[hidden email]> wrote:

> Keep track of your morphs.
>
> In Maui, you can have multiple views of the same identical object on
> the screen at once. Whenever you hover any one of them, all views of
> that same object on the screen are highlighted. When the mouse stops
> hovering over it, all views are unhighlighted.

That’s handling the converse (obverse?) of my problem; you get an event to one of your morphs and need to do something with all of them. In effect I get an event to not-one-of-my-morphs, need to find that out and do something. My current hack-around catches the event at a very early stage when no-one is quite sure who gets the event, but I rather suspect that it can’t work if the morph I *do* know about is embedded in another morph in the wrong place. Right now my morph is in the World, so it does get asked to reject. Not very satisfactory really.

I would think that quite a few cases could be handled cleanly if the focus got removed ‘properly’. Menus are one, but surely Halos would be more neatly handled that way too? And help balloons - both are specially tracked in PasteUpMorph/HandMorph et al. What about windows - when you swap to another window shouldn’t the old one get a defocus event to allow it to do whatever? Come to that, how *do* windows know to change the display of their windowframe buttons? (Oh, nasty - they track the specific top window)

I suspect that from the similarity of the code between the keyboard focus and mouse focus that that original intent was to make them behave very similarly. It’s certainly possible that, like so many things, it wasn’t needed urgently and got left behind. I’m not even sure that the mouse focus is consistently set at the moment, so trying to deal with changing it is a bit un-nerving.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Machine-independent: Does not run on any existing machine.

Bert Freudenberg

Re: Morph wants to know when it loses focus

On 13.02.2014, at 03:24, tim Rowledge <[hidden email]> wrote:

>
> On 12-02-2014, at 8:18 AM, Chris Muller <[hidden email]> wrote:
>
>> Keep track of your morphs.
>>
>> In Maui, you can have multiple views of the same identical object on
>> the screen at once. Whenever you hover any one of them, all views of
>> that same object on the screen are highlighted. When the mouse stops
>> hovering over it, all views are unhighlighted.
>
> That’s handling the converse (obverse?) of my problem; you get an event to one of your morphs and need to do something with all of them. In effect I get an event to not-one-of-my-morphs, need to find that out and do something. My current hack-around catches the event at a very early stage when no-one is quite sure who gets the event, but I rather suspect that it can’t work if the morph I *do* know about is embedded in another morph in the wrong place. Right now my morph is in the World, so it does get asked to reject. Not very satisfactory really.
>
> I would think that quite a few cases could be handled cleanly if the focus got removed ‘properly’. Menus are one, but surely Halos would be more neatly handled that way too? And help balloons - both are specially tracked in PasteUpMorph/HandMorph et al. What about windows - when you swap to another window shouldn’t the old one get a defocus event to allow it to do whatever? Come to that, how *do* windows know to change the display of their windowframe buttons? (Oh, nasty - they track the specific top window)
>
> I suspect that from the similarity of the code between the keyboard focus and mouse focus that that original intent was to make them behave very similarly. It’s certainly possible that, like so many things, it wasn’t needed urgently and got left behind. I’m not even sure that the mouse focus is consistently set at the moment, so trying to deal with changing it is a bit un-nerving.

What is mouse focus anyway? This only applies to some modal thingy, no?

I would think of mouse focus as the morph that handled the last mouse-down event: all mouse events should be routed to that morph until all mouse buttons are released. Something more permanent than this fleeting mode seems odd to me to call "mouse focus".

Having a "unified" framework for handling halos/menus/balloons etc sounds good, but it's not there, yet.

- Bert -

smime.p7s (5K) Download Attachment

Jecel Assumpcao Jr

Re: Morph wants to know when it loses focus

Bert Freudenberg wrote:
> What is mouse focus anyway? This only applies to some modal thingy, no?
>
> I would think of mouse focus as the morph that handled the last mouse-down
> event: all mouse events should be routed to that morph until all mouse
> buttons are released. Something more permanent than this fleeting mode
> seems odd to me to call "mouse focus".
>
> Having a "unified" framework for handling halos/menus/balloons etc sounds
> good, but it's not there, yet.

I really liked how the original Objective-C GUI "IC Pak" handled modal
stuff. It would just put a transparent "morph" the size of the screen on
top of everything and then put the modal dialog box, menu, help balloon
or whatever on top of that. As long as you stayed within the modal
morph, everything would work normally. But as soon as you clicked
outside of it, the transparent morph would intercept that, dismiss the
modal morph and itself (or whatever was the right thing to do with it)
and then resend the click event to whatever was under it (again, if this
was the right thing to do).

This has a very object-oriented feel to it compared to some state
machine or something like that.

-- Jecel

Eliot Miranda-2

Re: Morph wants to know when it loses focus

In reply to this post by Bert Freudenberg

On Thu, Feb 13, 2014 at 2:26 AM, Bert Freudenberg <[hidden email]> wrote:

On 13.02.2014, at 03:24, tim Rowledge <[hidden email]> wrote:

>
> On 12-02-2014, at 8:18 AM, Chris Muller <[hidden email]> wrote:
>
>> Keep track of your morphs.
>>
>> In Maui, you can have multiple views of the same identical object on
>> the screen at once. Whenever you hover any one of them, all views of
>> that same object on the screen are highlighted. When the mouse stops
>> hovering over it, all views are unhighlighted.
>
> That’s handling the converse (obverse?) of my problem; you get an event to one of your morphs and need to do something with all of them. In effect I get an event to not-one-of-my-morphs, need to find that out and do something. My current hack-around catches the event at a very early stage when no-one is quite sure who gets the event, but I rather suspect that it can’t work if the morph I *do* know about is embedded in another morph in the wrong place. Right now my morph is in the World, so it does get asked to reject. Not very satisfactory really.
>
> I would think that quite a few cases could be handled cleanly if the focus got removed ‘properly’. Menus are one, but surely Halos would be more neatly handled that way too? And help balloons - both are specially tracked in PasteUpMorph/HandMorph et al. What about windows - when you swap to another window shouldn’t the old one get a defocus event to allow it to do whatever? Come to that, how *do* windows know to change the display of their windowframe buttons? (Oh, nasty - they track the specific top window)
>
> I suspect that from the similarity of the code between the keyboard focus and mouse focus that that original intent was to make them behave very similarly. It’s certainly possible that, like so many things, it wasn’t needed urgently and got left behind. I’m not even sure that the mouse focus is consistently set at the moment, so trying to deal with changing it is a bit un-nerving.

What is mouse focus anyway? This only applies to some modal thingy, no?

Ugh. I *hate* the lack of mouse focus. I don't know how many times in filling in the commit dialog my typing stream has been redirected to the package version, or to the void of the desktop. This lack of focus for text input is so broken.

I would think of mouse focus as the morph that handled the last mouse-down event: all mouse events should be routed to that morph until all mouse buttons are released. Something more permanent than this fleeting mode seems odd to me to call "mouse focus".

Having a "unified" framework for handling halos/menus/balloons etc sounds good, but it's not there, yet.

- Bert -

--
best,

Eliot

Bert Freudenberg

Re: Morph wants to know when it loses focus

On 13.02.2014, at 21:34, Eliot Miranda <[hidden email]> wrote:

On Thu, Feb 13, 2014 at 2:26 AM, Bert Freudenberg <[hidden email]> wrote:

On 13.02.2014, at 03:24, tim Rowledge <[hidden email]> wrote:

>
> On 12-02-2014, at 8:18 AM, Chris Muller <[hidden email]> wrote:
>
>> Keep track of your morphs.
>>
>> In Maui, you can have multiple views of the same identical object on
>> the screen at once. Whenever you hover any one of them, all views of
>> that same object on the screen are highlighted. When the mouse stops
>> hovering over it, all views are unhighlighted.
>
> That’s handling the converse (obverse?) of my problem; you get an event to one of your morphs and need to do something with all of them. In effect I get an event to not-one-of-my-morphs, need to find that out and do something. My current hack-around catches the event at a very early stage when no-one is quite sure who gets the event, but I rather suspect that it can’t work if the morph I *do* know about is embedded in another morph in the wrong place. Right now my morph is in the World, so it does get asked to reject. Not very satisfactory really.
>
> I would think that quite a few cases could be handled cleanly if the focus got removed ‘properly’. Menus are one, but surely Halos would be more neatly handled that way too? And help balloons - both are specially tracked in PasteUpMorph/HandMorph et al. What about windows - when you swap to another window shouldn’t the old one get a defocus event to allow it to do whatever? Come to that, how *do* windows know to change the display of their windowframe buttons? (Oh, nasty - they track the specific top window)
>
> I suspect that from the similarity of the code between the keyboard focus and mouse focus that that original intent was to make them behave very similarly. It’s certainly possible that, like so many things, it wasn’t needed urgently and got left behind. I’m not even sure that the mouse focus is consistently set at the moment, so trying to deal with changing it is a bit un-nerving.

What is mouse focus anyway? This only applies to some modal thingy, no?

Ugh. I *hate* the lack of mouse focus. I don't know how many times in filling in the commit dialog my typing stream has been redirected to the package version, or to the void of the desktop. This lack of focus for text input is so broken.

No no, that's *keyboard focus* which assures keyboard events go to the focused widget. Tim's talking about "mouse focus" and I want to know what's that supposed to be.

I would think of mouse focus as the morph that handled the last mouse-down event: all mouse events should be routed to that morph until all mouse buttons are released. Something more permanent than this fleeting mode seems odd to me to call "mouse focus".

Having a "unified" framework for handling halos/menus/balloons etc sounds good, but it's not there, yet.

- Bert -

--
best,
Eliot

- Bert -

smime.p7s (5K) Download Attachment

timrowledge

Re: Morph wants to know when it loses focus

On 13-02-2014, at 1:13 PM, Bert Freudenberg <[hidden email]> wrote:
[snip]

>>
>> What is mouse focus anyway? This only applies to some modal thingy, no?
>>
>> Ugh. I *hate* the lack of mouse focus. I don't know how many times in filling in the commit dialog my typing stream has been redirected to the package version, or to the void of the desktop. This lack of focus for text input is so broken.
>
> No no, that's *keyboard focus* which assures keyboard events go to the focused widget. Tim's talking about "mouse focus" and I want to know what's that supposed to be.
>
>>
>> I would think of mouse focus as the morph that handled the last mouse-down event: all mouse events should be routed to that morph until all mouse buttons are released. Something more permanent than this fleeting mode seems odd to me to call "mouse focus".
>>
>> Having a "unified" framework for handling halos/menus/balloons etc sounds good, but it's not there, yet.

I’m much more in a mode of asking than prescribing.

Looking at HandMorph I see how it is currently only given a new mouse focus during a mouse-down handler and that is released during various grabs, deletes and mouse-up handlers. It seems like the focus is predominantly used to speed up dispatching events when there is some indication that we should already know where to send it, which is a nice idea.

I had a vague idea that perhaps adding a mouseListener would be the right way to do what I need but ran into finding out which hand to add it to.

More ideas needed on this one; anyone? Beuhler?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange Opcodes: ZZZZZZZZZZZZ: enter sleep mode

Bert Freudenberg

Re: Morph wants to know when it loses focus

On 13.02.2014, at 22:42, tim Rowledge <[hidden email]> wrote:

> On 13-02-2014, at 1:13 PM, Bert Freudenberg <[hidden email]> wrote:
> [snip]
>>>
>>> What is mouse focus anyway? This only applies to some modal thingy, no?
>>>
>>> Ugh. I *hate* the lack of mouse focus. I don't know how many times in filling in the commit dialog my typing stream has been redirected to the package version, or to the void of the desktop. This lack of focus for text input is so broken.
>>
>> No no, that's *keyboard focus* which assures keyboard events go to the focused widget. Tim's talking about "mouse focus" and I want to know what's that supposed to be.
>>
>>>
>>> I would think of mouse focus as the morph that handled the last mouse-down event: all mouse events should be routed to that morph until all mouse buttons are released. Something more permanent than this fleeting mode seems odd to me to call "mouse focus".
>>>
>>> Having a "unified" framework for handling halos/menus/balloons etc sounds good, but it's not there, yet.
>
> I’m much more in a mode of asking than prescribing.
>
> Looking at HandMorph I see how it is currently only given a new mouse focus during a mouse-down handler and that is released during various grabs, deletes and mouse-up handlers. It seems like the focus is predominantly used to speed up dispatching events when there is some indication that we should already know where to send it, which is a nice idea.
>
> I had a vague idea that perhaps adding a mouseListener would be the right way to do what I need but ran into finding out which hand to add it to.
>
> More ideas needed on this one; anyone? Beuhler?

Ah, so it is indeed what I described. It's there to ensure that if a morph got a mouse down, it will also get the corresponding mouse-up, no matter what. And that no other morph gets an up without a down.

- Bert -

smime.p7s (5K) Download Attachment