On Thu, Feb 13, 2014 at 2:26 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 13.02.2014, at 03:24, tim Rowledge <tim at rowledge.org> wrote:
>
> >
> > 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.
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140213/f65390ff/attachment.htm