On 12-02-2014, at 8:18 AM, Chris Muller <asqueaker at gmail.com> 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; tim at rowledge.org; http://www.rowledge.org/tim
Machine-independent:  Does not run on any existing machine.