mouse enter/move/leave event confusion

I’m trying to provide the appearance of a cursor that is gridded in a paint program; the idea is that the tool cursor should jump only to positions on the grid and when the bitmap is scaled to say 4X that would be every 4th pixel position on the screen.

Since making the actual HandMorph & real cursor do gridding seemed a bit of a heavyweight thing to impose on everything else, I’m attempting to do it by handling mousemove events within my painting canvas morph. It *almost* works but there is something very odd going on at far too frequent occasions.

So far as I can currently tell the event handling code up in Morph & HandMorph is sometimes deciding that the mouse has left my morph and thus sends me a mouseleave event instead of a a move. Then as soon as the cursor moves, I get a new mouseenter and more moves until whatever it is upsets things again. There’s some unpleasantly complex code up at MouseOverHandler>processMouseOver: for example that appears to be in the middle of my problem - best I can tell is that ‘leftMorphs’ is somehow including my morph when the mouse is still right there in the middle of it.

My basic scheme is to create a suitable ImageMorph on the mouseEnter, change its position with each mouseMove and then delete it on mouseLeave.  I have implemented handlesMouseMove: to always return true, so I seem to get all the move events.

Any idea about why I get the dud mouseLeave events? Has anyone else done a scaled-up-grid-cursor thingy?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Pak Protectors does it take to change a lightbulb?”
"Only one, but the lightbulb has to smell right."

Hi Tim,

yes, mouse-leave and mouse-enter events occur more than what a user would expect. Also, when you speed up your mouse movements there is a chance that you will not get a mouse-leave event at all.

Find attached some code that works fine. :) Without gridding but that could easily be added.

Sandbox.st

Best,
Marcel

> On 02-12-2015, at 2:21 AM, marcel.taeumel <[hidden email]> wrote:
> yes, mouse-leave and mouse-enter events occur more than what a user would
> expect. Also, when you speed up your mouse movements there is a chance that
> you will not get a mouse-leave event at all.
>

Oh dear. That really shouldn’t happen.


> Find attached some code that works fine. :) Without gridding but that could
> easily be added.

Yah, that’s almost exactly what my code looks like wrt the events etc. The only difference is that my ‘cursor’ isn’t a submorph of the ‘playfield’. I wonder if that would help at all...


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Performance is easier to add than clarity.

> On 02-12-2015, at 11:11 AM, tim Rowledge <[hidden email]> wrote:
>
>> Find attached some code that works fine. :) Without gridding but that could
>> easily be added.
>
> Yah, that’s almost exactly what my code looks like wrt the events etc. The only difference is that my ‘cursor’ isn’t a submorph of the ‘playfield’. I wonder if that would help at all…

Well, it sort of did and sort of didn’t. It certainly removed the appearance of the fake-cursor jumping around due to spurious mouse-leaves. But unfortunately it *crushed* performance and made painting horribly slow. A Tally implied some horrible volume of draw related messages that don’t happen normally. Sigh.

So right now I’m wondering if I can make the HandMorph’s temporaryCursor be some variety of form/morph that does the gridding while displaying. The issue there is that all the relevant code expects the temporaryCursor to be an image, so a lot would need fiddling with.

I guess another option might be to subclass HandMorph to try out adding more instvars and add gridding that way. At least that might avoid breaking everyone else’s Hands. ;-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His head whistles in a cross wind.

Unfortunately, it is not possible anymore to modify the mouse position programmatically. You approach with an additional cursor seems reasonable.

That slow-down can occur because your paint area is a single morph? How does it draw? If you want efficient redraw with the damage-recorder working, you should use morph composition. Every stroke should be a morph. This can speed-up drawing routine.

Can you show some code?

Best,
Marcel

Hi,
so now I know why I can get so many spurious enter/leave events. It’s really embarrassingly dumb…

When you are dragging a morph around and have the morph positioned at the event cursor point - ie not centred under it as you eventually want - then moving even moderately quickly can result in the cursor point being over the dragged morph. Which is not the canvas morph. So you’ve left the canvas morph; and you get a mouse leave event. D’oh! Then the fake-cursor-morph gets deleted, you are now over the canvas morph so you get a mouse enter event, and so on.

I worked this out eventually because I added the centring offset negated and so the fake-cursor was well out of the way and hardly any enter/leave events came in.  When I ‘corrected' the offset, everything was flashing madly as gazillions of enter/leaves flooded the place since the morph was directly under the cursor and thus always causing a leave event.

Thus my conclusion is that we can’t drag a morph around like this. Sigh.

It looks like adding some code to grid-step in HandMorph>position: is the only way to proceed now.
I’m going to work on the assumption that only the temporary cursor needs to worry about it, though if people want the cursor in general to grid it wouldn’t be hard to expand that. I’m not hugely keen on messing with HandMorph since it is so central to the UI so I’ll stick with a couple of globals or properties for the gridding info for now.

One question for you all - if I added a subclass GriddingHandMorph, how tricky is it to swap the current hand around. Could I reasonably swap to a gridded hand when entering my canvas morph and back to an ordinary one on leave? Would it be saner to just swap to a gridded hand in my product image and leave it at that?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: TVO: Type Various Obscenities

> On 03-12-2015, at 4:54 PM, tim Rowledge <[hidden email]> wrote:
>
> It looks like adding some code to grid-step in HandMorph>position: is the only way to proceed now.
> I’m going to work on the assumption that only the temporary cursor needs to worry about it, though if people want the cursor in general to grid it wouldn’t be hard to expand that. I’m not hugely keen on messing with HandMorph since it is so central to the UI so I’ll stick with a couple of globals or properties for the gridding info for now.

Using a couple of properties for now I can get pretty good results. There are a couple of places in my painting code that need mild hacks because the events sent are*not* gridded right now, only the hand position is and only when using a temporary cursor as well.
IF everyone likes the idea of having the ability to grid the cursor and mouse event positions as a general thing we could look into all the places that would need changes.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Mellita, domi adsum. = Honey, I'm home.

You can try optimizing hat mouse enter/leave thing with HandMorph >> #newMouseFocus:. If your "canvas" morph receives all the mouse events, you can drop additional mouse enter/leave events.

Do you have some code for us? ;)

Best,
Marcel

On 04-12-15 01:54, tim Rowledge wrote:
> Hi,
> so now I know why I can get so many spurious enter/leave events. It’s really embarrassingly dumb…
>
> When you are dragging a morph around and have the morph positioned at the event cursor point - ie not centred under it as you eventually want - then moving even moderately quickly can result in the cursor point being over the dragged morph. Which is not the canvas morph. So you’ve left the canvas morph; and you get a mouse leave event. D’oh! Then the fake-cursor-morph gets deleted, you are now over the canvas morph so you get a mouse enter event, and so on.

Hmm. conceptually I would expect to get no spurious enter/leaves when
the morph you're dragging around is either a submorph of the canvas, or
grabbed by the hand.

Stephan

> On 04.12.2015, at 11:33, Stephan Eggermont <[hidden email]> wrote:
>
> On 04-12-15 01:54, tim Rowledge wrote:
>> Hi,
>> so now I know why I can get so many spurious enter/leave events. It’s really embarrassingly dumb…
>>
>> When you are dragging a morph around and have the morph positioned at the event cursor point - ie not centred under it as you eventually want - then moving even moderately quickly can result in the cursor point being over the dragged morph. Which is not the canvas morph. So you’ve left the canvas morph; and you get a mouse leave event. D’oh! Then the fake-cursor-morph gets deleted, you are now over the canvas morph so you get a mouse enter event, and so on.
>
> Hmm. conceptually I would expect to get no spurious enter/leaves when the morph you're dragging around is either a submorph of the canvas, or grabbed by the hand.

This. A grabbed morph is not in the world so should not generate events.

- Bert -

Oh, and I thought you were going to use the temp cursor? Why wouldn’t that work?

- Bert -

Why grabbing if you just need an indication (for the gridding) where the next stroke will go on a mouse down/click?

Best,
Marcel

> On 04-12-2015, at 2:33 AM, Stephan Eggermont <[hidden email]> wrote:
>
> Hmm. conceptually I would expect to get no spurious enter/leaves when the morph you're dragging around is either a submorph of the canvas, or grabbed by the hand.

Well, I’ve now done this I think four ways, so roughly speaking -
a) making a morph  as a fake-cursor, opening it in the World and dragging it around via the canvas’ mouseEnter/Move/Leave messages doesn’t work well. I got many leave/enter messages and so the fake-cursor would get deleted and recreated very often. Also, since my mouse enter code made the morph and opened it it would appear in the top-left before flickering to the ‘proper’ place and then back and forth with each leave/enter.
b) the next try added the fake-cursor as a submorph of the canvas, which caused some interesting layout issues until I noticed that it really ought to get position before adding it. It worked relatively well except for ruining performance.
c) another attempt at a) along with centring the morph on the cursor position showed me the error of my ways and explained the spurious leave/enter flickering.
d) the latest code adds gridding to the HandMorph if and only if there is a temporaryCursor set.

Using the ‘attach’ protocol simply didn’t occur to me. Which is crazy since I’ve used it enough to drag blocks and sprites around. Perhaps I’ll try it out.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A sad tale that brings a lump to the eye and a tear to the throat.

Just a thought: If users only see a cursor that jumps along some grid, users might err too often. Especially if that grid is rather big.

Best,
Marcel