Re: [Pipmak-Devel] Transition interrupts

[Christian W. <cwa...@gm...>]

Aidan Gauland wrote:
>  I've managed to do something to the code for handling mouse button 
> up/down events, which SEEMS to fix the problem of starting a transition 
> during a transition, but there might still be something more subtle I've 
> overlooked.  I've attached a patch, generated against revision 179.

Thanks for looking into this! This solution seems a bit too simplistic, 
however. Here is a test case where it causes incorrect behavior:

---8<--- node.lua ------------------------------------------------------

slide (pipmak.newimage(640, 480):color(1.0, 0.95, .8):fill())

local btnimg = pipmak.newimage(100, 40):color(0.5, 0.5, 0.7):fill()
local btnimgh = pipmak.newimage(100, 40):color(0.7, 0.3, 0.3):fill()

local indicator = patch { x = 200, y = 100, image = pipmak.newimage(40, 
40):color(0.5, 0.8, 0.3):fill() }

local btn = patch { x = 270, y = 300, image = btnimg }
handle {
	x = 270, y = 300, w = 100, h = 40,
	onhilite = function(self, h)
		btn:setimage(h and btnimgh or btnimg)
	end,
	onmousedown = function()
		indicator:moveto(200, 100)
		pipmak.schedule(2, function()
			indicator:moveto(300, 100)
			pipmak.dissolve(1, 4)
			indicator:moveto(400, 100)
			pipmak.schedule(4, function()
				indicator:moveto(500, 100)			
			end)
		end)
	end
}

---8<-------------------------------------------------------------------

The blue rectangle is a button that highlights red when clicked. Mouse 
down on this button starts the following sequence: The green square 
resets to position 1. After 2 seconds, it jumps to position 2 and starts 
fading to position 3. The transition takes 4 seconds, when it's done the 
green square jumps to position 4.

When you press the mouse button on the blue button and hold it down 
until the transition starts, then release it while the transition is 
running, the button does not properly unhighlight (return from red to 
blue) since the mouse-up event is suppressed.

Off the top of my head, here's the behavior I would propose:
- When the mouse goes down during a transition, the entire click 
(including mouse up, whether it happens before the end of the transition 
or after) should be ignored.
- Not sure if this is necessary: When the mouse is down at the beginning 
of a transition and goes up during it, the mouse-up event should be 
delayed until the transition has finished.

Does that make sense?

And two general comments:
- It looks like you still generated the patch "by hand" using diff. If 
you're using Subversion now (as I assume when you say "revision 179"), 
it would probably be more convenient to use "svn diff".
- You're again using a mixture of tabs and spaces for indentation. You 
won't get commit access until you get this right (tabs only) ;)

>  And about the bug with grabbing the mouse after closing a dialog...
> flashback:
>  > Also, when I bring up the save game dialog with the 'S' key, Pipmak 
>  >doesn't give me my mouse back, and I have to go to a virtual console 
>  >and kill Pipmak.  If I add a call to SDL_WM_GrabInput() to ungrab the 
>  >mouse in the Lua C function which is called when the 'S' key is 
>  >pressed, that seems to solve this problem.

Hmm, I thought you fixed that in rev. 179? Or are you talking about the 
other problem, the one you described as

> Ahhh, one other thing: If the user brings up a dialog, and then dismisses
> it, Pipmak seems to do the same thing with grabbing the mouse, even if it's
> not in the window, and then it is impossible to get the mouse out of the
> window, until the user brings up another dialog, and closes it when it is
> over the Pipmak window (so the mouse will be in the Pipmak window when it
> regrabs the mouse).
?

> I think it might only show wiht GTK.  If I understand this properly, 
> Pipmak uses GTK when built for Linux, and Aqua when built for Macintosh. 
>  So that might be why Christian doesn't get this bug.

Well, it's true that I don't get it on Mac OS, but I don't even get it 
with GTK on Linux.

>  If I add a call to the SDL warp mouse function, at the end Lua function 
> for the save dialog (the one called when the 'S' key is pressed), that 
> seems to work as a crude workaround, but I don't know how to find a 
> better solution.

Just send us that workaround, I'll commit it if it doesn't break 
anything. Maybe Urs can test it as well, and I'll make sure to test on 
Ubuntu (where I assume I'll have the same behavior as you on Debian) 
before the release anyway.

  -Christian