[Cuis-dev] Recent changes in MouseEvent dispatching and Kayboard focus and events

[Juan Vuletich]

Hi Hilaire,

On 23/09/2025 12:42 PM, Hilaire Fernandes via Cuis-dev wrote:
>
> Hi Juan,
>
> Let me try to understand completely the mouseMove changes.
>
> So you don't need anymore handlesMouseDown: answering true to get the 
> message #mouseMove.. sent to each morph the mouse is hovering, is that 
> correct?
>
> I am wondering if it makes the message name a bit missleading. I was 
> thinking it sounds more like mouseHovering. Well, ok, maybe not.
>
I didn't address naming this time. We could, though, at the cost of 
additional compatibility bumps. Still, a good thing to do.

> Will not it make the UI a bit too much verbose with this message sent 
> systematically to each morph the mouse is hovering?
>
You mean slow? The more expensive part is actually finding the possible 
morph to send the event to. Once we found it, asking it if it wants the 
event, or just sending it a message that won't do anything at all is 
equally expensive (or cheap).

Thanks,

> Thanks
>
> Hilaire
>
> Le 23/09/2025 à 16:14, Juan Vuletich via Cuis-dev a écrit :
>> - MouseMoveEvent. Before, only morphs that answered true to 
>> #handlesMouseDown: would get them. Except for InnerTextMorph that 
>> used them to highlight and enable links in text. This made me think 
>> that any morph could make good use of MouseMove event if no mouse 
>> button is pressed. So I made that change. Now, most implementors of 
>> #mouseMove:localPosition: need to ask `aMouseMoveEvent 
>> anyButtonPressed` before doing their stuff. Your morphs should most 
>> likely do the same. 
> -- 
> http://mamot.fr/@drgeo
>
-- 
Juan Vuletich
www.cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20250923/962c45d0/attachment-0001.htm>