On 13-02-2014, at 1:13 PM, Bert Freudenberg <bert at freudenbergs.de> 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; tim at rowledge.org; http://www.rowledge.org/tim
Strange Opcodes: ZZZZZZZZZZZZ: enter sleep mode