Re: [Pipmak-Devel] Transition interrupts

[Aidan G. <wgs...@ih...>]

  Using your Lua code, I was able to make chamges to Pipmak, so it will 
now ignore a click during a transition, but will also ignore the button 
up event ONLY if it is from a click DURING a transition.  It would 
probably make more sense if you look at my changes.

  And I am sending the patch for my workaround for the bug where Pipmak 
grabs the mouse if the user clicks cancel on the save game dialog. 
Maybe not the best solution, but I don't think it broke anything.

  I have messed around with my text editor's settings, so it should only 
be using tabs now.  Please let me know if it isn't.

  Oh, I almost forgot, I'm also sending a patch to the file 
build-linux/Makefile, which changes the path to look for the Lua, and 
PhysFS libraries.  It changes the paths to where the Debain packages for 
these libraries get installed, but I don't know if it would work for 
non-Debain Linux systems.


Christian Walther wrote:
> 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
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pipmak-Devel mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
>