<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 2:26 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 13.02.2014, at 03:24, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
<br>
><br>
> On 12-02-2014, at 8:18 AM, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
><br>
>> Keep track of your morphs.<br>
>><br>
>> In Maui, you can have multiple views of the same identical object on<br>
>> the screen at once. Whenever you hover any one of them, all views of<br>
>> that same object on the screen are highlighted. When the mouse stops<br>
>> hovering over it, all views are unhighlighted.<br>
><br>
> 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.<br>
><br>
> 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)<br>
><br>
> 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.<br>
<br>
What is mouse focus anyway? This only applies to some modal thingy, no?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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".<br>
<br>
Having a "unified" framework for handling halos/menus/balloons etc sounds good, but it's not there, yet.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Bert -<br>
<br>
<br>
</font></span><br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>