pipmak-devel

[Pipmak-Devel] Transition interrupts

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

Hello,

  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.

  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.

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.  However, I have 
no idea if the bug is in GTK, Pipmak's code for using GTK, or with SDL. 
  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.

  -Aidan

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

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
> 

Re: [Pipmak-Devel] Transition interrupts

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

Aidan Gauland wrote:
>  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.

Looks good, from the distance (I don't have time to really test it right 
now). I wonder, would any bad things happen if you'd check for "&& 
mouseButton != 0" instead of "&& clickDuringTransition == 0" in the 
SDL_MOUSEBUTTONUP case? Then you could get rid of the new 
clickDuringTransition variable.

>  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.

Thanks, this is committed (without extensive testing): rev. 180.

>  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.

Looks good now. :)

>  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.

This means that the instructions in Building.txt wouldn't work anymore. 
You'd need to change these instructions too. But even then I'm not sure 
if I want this. Can we rely on all distributions having packages for Lua 
and Physfs? Perhaps something could be done with automatically 
determining whether these libraries are present in the system, and 
otherwise use the ones installed in the build-linux folder according to 
the instructions? Would it be possible to use system-installed libraries 
without modifying the makefile by placing symlinks in build-linux?

Also, you're linking Lua and Physfs dynamically now (assuming their 
Debian packages include dynamic libraries). That's fine when you're 
compiling from source, but for the distributed binary I'd rather move 
towards linking more libraries statically, not less, to avoid dependency 
problems.

Is there a reason for the removal of two empty lines?

  -Christian

Re: [Pipmak-Devel] Transition interrupts

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

Christian Walther wrote:
> Aidan Gauland wrote:
>>  Using your Lua code, I was able to make changes 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.
> 
> Looks good, from the distance (I don't have time to really test it right 
> now). I wonder, would any bad things happen if you'd check for "&& 
> mouseButton != 0" instead of "&& clickDuringTransition == 0" in the 
> SDL_MOUSEBUTTONUP case? Then you could get rid of the new 
> clickDuringTransition variable.

  Wouldn't that just be, in English:  "If a mouse button is down"?
If another button was still down when one comes up, how would that tell 
us if the click was from before a transition or not?

>>  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.
> 
> Thanks, this is committed (without extensive testing): rev. 180.
> 
>>  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.
> 
> Looks good now. :)
> 
>>  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.
> 
> This means that the instructions in Building.txt wouldn't work anymore. 
> You'd need to change these instructions too. But even then I'm not sure 
> if I want this. Can we rely on all distributions having packages for Lua 
> and Physfs? Perhaps something could be done with automatically 
> determining whether these libraries are present in the system, and 
> otherwise use the ones installed in the build-linux folder according to 
> the instructions? Would it be possible to use system-installed libraries 
> without modifying the makefile by placing symlinks in build-linux?

  I tried that, and it didn't work, but it might, if I changed the make 
file, in which case I might as well change it in the way that I did.

> Also, you're linking Lua and Physfs dynamically now (assuming their 
> Debian packages include dynamic libraries). That's fine when you're 
> compiling from source, but for the distributed binary I'd rather move 
> towards linking more libraries statically, not less, to avoid dependency 
> problems.
> 
> Is there a reason for the removal of two empty lines?

  I think Lua is pretty widely available on Linux distributions, but I 
don't know about PhysFS.  And the removal of the two lines is just so 
Emacs doesn't give ma a warning.  What about adding an optional patch 
for the Makefile?

>   -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
> 

Re: [Pipmak-Devel] Transition interrupts

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

Aidan Gauland wrote:
> Christian Walther wrote:
>> Aidan Gauland wrote:
>>>  Using your Lua code, I was able to make changes 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.
>> Looks good, from the distance (I don't have time to really test it right 
>> now). I wonder, would any bad things happen if you'd check for "&& 
>> mouseButton != 0" instead of "&& clickDuringTransition == 0" in the 
>> SDL_MOUSEBUTTONUP case? Then you could get rid of the new 
>> clickDuringTransition variable.
> 
>   Wouldn't that just be, in English:  "If a mouse button is down"?

"If a mouse button is down from the point of view of Pipmak", yes. Not 
necessarily "if a mouse button is physically down", since you skip 
setting mouseButton to non-zero at SDL_MOUSEBUTTONDOWN if 
TRANSITION_RUNNING.

> If another button was still down when one comes up, how would that tell 
> us if the click was from before a transition or not?

"one mouse button coming up while another one is still down" is not a 
mouse-up event from the point of view of Pipmak. Mouse-up doesn't happen 
until *all* buttons are up. That's what made most sense to me when I 
decided to have Pipmak expose a one-button-mouse interface to projects.

>>>  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.
>> This means that the instructions in Building.txt wouldn't work anymore. 
>> You'd need to change these instructions too. But even then I'm not sure 
>> if I want this. Can we rely on all distributions having packages for Lua 
>> and Physfs? Perhaps something could be done with automatically 
>> determining whether these libraries are present in the system, and 
>> otherwise use the ones installed in the build-linux folder according to 
>> the instructions? Would it be possible to use system-installed libraries 
>> without modifying the makefile by placing symlinks in build-linux?
> 
>   I tried that, and it didn't work, but it might, if I changed the make 
> file, in which case I might as well change it in the way that I did.

OK.

>> Also, you're linking Lua and Physfs dynamically now (assuming their 
>> Debian packages include dynamic libraries). That's fine when you're 
>> compiling from source, but for the distributed binary I'd rather move 
>> towards linking more libraries statically, not less, to avoid dependency 
>> problems.
>>
>> Is there a reason for the removal of two empty lines?
> 
>   I think Lua is pretty widely available on Linux distributions, but I 
> don't know about PhysFS.  And the removal of the two lines is just so 
> Emacs doesn't give ma a warning.

What does that warning say?

> What about adding an optional patch for the Makefile?

I think it would be easier to maintain if we could either autodetect the 
presence of system-installed libraries (do they include pkg-config files 
or anything?), or provide a command-line argument to switch to using 
them ("make use_system_lua=1 pipmak" or something).

  -Christian

Re: [Pipmak-Devel] Transition interrupts

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

Christian Walther wrote:
> Aidan Gauland wrote:
>> Christian Walther wrote:
>>> Aidan Gauland wrote:
>>>>  Using your Lua code, I was able to make changes 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.
>>> Looks good, from the distance (I don't have time to really test it right 
>>> now). I wonder, would any bad things happen if you'd check for "&& 
>>> mouseButton != 0" instead of "&& clickDuringTransition == 0" in the 
>>> SDL_MOUSEBUTTONUP case? Then you could get rid of the new 
>>> clickDuringTransition variable.
>>   Wouldn't that just be, in English:  "If a mouse button is down"?
> 
> "If a mouse button is down from the point of view of Pipmak", yes. Not 
> necessarily "if a mouse button is physically down", since you skip 
> setting mouseButton to non-zero at SDL_MOUSEBUTTONDOWN if 
> TRANSITION_RUNNING.
> 
>> If another button was still down when one comes up, how would that tell 
>> us if the click was from before a transition or not?
> 
> "one mouse button coming up while another one is still down" is not a 
> mouse-up event from the point of view of Pipmak. Mouse-up doesn't happen 
> until *all* buttons are up. That's what made most sense to me when I 
> decided to have Pipmak expose a one-button-mouse interface to projects.

  Ok, that makes sense, I'm sending another patch (generated r180), 
which does the same thing as the last one, but with no extra variable.

>>>>  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.
>>> This means that the instructions in Building.txt wouldn't work anymore. 
>>> You'd need to change these instructions too. But even then I'm not sure 
>>> if I want this. Can we rely on all distributions having packages for Lua 
>>> and Physfs? Perhaps something could be done with automatically 
>>> determining whether these libraries are present in the system, and 
>>> otherwise use the ones installed in the build-linux folder according to 
>>> the instructions? Would it be possible to use system-installed libraries 
>>> without modifying the makefile by placing symlinks in build-linux?
>>   I tried that, and it didn't work, but it might, if I changed the make 
>> file, in which case I might as well change it in the way that I did.
> 
> OK.
> 
>>> Also, you're linking Lua and Physfs dynamically now (assuming their 
>>> Debian packages include dynamic libraries). That's fine when you're 
>>> compiling from source, but for the distributed binary I'd rather move 
>>> towards linking more libraries statically, not less, to avoid dependency 
>>> problems.
>>>
>>> Is there a reason for the removal of two empty lines?
>>   I think Lua is pretty widely available on Linux distributions, but I 
>> don't know about PhysFS.  And the removal of the two lines is just so 
>> Emacs doesn't give me a warning.
> 
> What does that warning say?

Just something like "suspicious blank line".  Yeah, I know, big help.

>> What about adding an optional patch for the Makefile?
> 
> I think it would be easier to maintain if we could either autodetect the 
> presence of system-installed libraries (do they include pkg-config files 
> or anything?), or provide a command-line argument to switch to using 
> them ("make use_system_lua=1 pipmak" or something).

  I have no idea, I haven't ever used make (except for building other
people's projects).  But I know that on the distribution Gentoo (not 
based on Debain), all packages are source, and the package management 
system is completely different from apt and dpkg (Debians package 
management tools).  My point is that you might have to take a more 
general approach to work on as many Linux distributions as possible.

> 
>   -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
> 

Re: [Pipmak-Devel] Transition interrupts

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

Ok, that was stupid.  I forgot the attachment.  THIS message has it.

Aidan Gauland wrote:
> Christian Walther wrote:
>> Aidan Gauland wrote:
>>> Christian Walther wrote:
>>>> Aidan Gauland wrote:
>>>>>  Using your Lua code, I was able to make changes 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.
>>>> Looks good, from the distance (I don't have time to really test it right 
>>>> now). I wonder, would any bad things happen if you'd check for "&& 
>>>> mouseButton != 0" instead of "&& clickDuringTransition == 0" in the 
>>>> SDL_MOUSEBUTTONUP case? Then you could get rid of the new 
>>>> clickDuringTransition variable.
>>>   Wouldn't that just be, in English:  "If a mouse button is down"?
>> "If a mouse button is down from the point of view of Pipmak", yes. Not 
>> necessarily "if a mouse button is physically down", since you skip 
>> setting mouseButton to non-zero at SDL_MOUSEBUTTONDOWN if 
>> TRANSITION_RUNNING.
>>
>>> If another button was still down when one comes up, how would that tell 
>>> us if the click was from before a transition or not?
>> "one mouse button coming up while another one is still down" is not a 
>> mouse-up event from the point of view of Pipmak. Mouse-up doesn't happen 
>> until *all* buttons are up. That's what made most sense to me when I 
>> decided to have Pipmak expose a one-button-mouse interface to projects.
> 
>   Ok, that makes sense, I'm sending another patch (generated r180), 
> which does the same thing as the last one, but with no extra variable.
> 
>>>>>  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.
>>>> This means that the instructions in Building.txt wouldn't work anymore. 
>>>> You'd need to change these instructions too. But even then I'm not sure 
>>>> if I want this. Can we rely on all distributions having packages for Lua 
>>>> and Physfs? Perhaps something could be done with automatically 
>>>> determining whether these libraries are present in the system, and 
>>>> otherwise use the ones installed in the build-linux folder according to 
>>>> the instructions? Would it be possible to use system-installed libraries 
>>>> without modifying the makefile by placing symlinks in build-linux?
>>>   I tried that, and it didn't work, but it might, if I changed the make 
>>> file, in which case I might as well change it in the way that I did.
>> OK.
>>
>>>> Also, you're linking Lua and Physfs dynamically now (assuming their 
>>>> Debian packages include dynamic libraries). That's fine when you're 
>>>> compiling from source, but for the distributed binary I'd rather move 
>>>> towards linking more libraries statically, not less, to avoid dependency 
>>>> problems.
>>>>
>>>> Is there a reason for the removal of two empty lines?
>>>   I think Lua is pretty widely available on Linux distributions, but I 
>>> don't know about PhysFS.  And the removal of the two lines is just so 
>>> Emacs doesn't give me a warning.
>> What does that warning say?
> 
> Just something like "suspicious blank line".  Yeah, I know, big help.
> 
>>> What about adding an optional patch for the Makefile?
>> I think it would be easier to maintain if we could either autodetect the 
>> presence of system-installed libraries (do they include pkg-config files 
>> or anything?), or provide a command-line argument to switch to using 
>> them ("make use_system_lua=1 pipmak" or something).
> 
>   I have no idea, I haven't ever used make (except for building other
> people's projects).  But I know that on the distribution Gentoo (not 
> based on Debain), all packages are source, and the package management 
> system is completely different from apt and dpkg (Debians package 
> management tools).  My point is that you might have to take a more 
> general approach to work on as many Linux distributions as possible.
> 
>>   -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
>>
> 
> -------------------------------------------------------------------------
> 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
> 

Re: [Pipmak-Devel] Transition interrupts

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

Aidan Gauland wrote:
>   Ok, that makes sense, I'm sending another patch (generated r180), 
> which does the same thing as the last one, but with no extra variable.

Thanks, this is in - rev. 181.

> My point is that you might have to take a more general approach to work on as many Linux distributions as possible.

That's exactly what I was trying to do by not requiring system-installed 
versions of Lua and Physfs. It takes a bit more hand work for the 
builder, but we can stick with a single Makefile, which seems more 
maintainable to me than having several ones, or one and a set of patches 
on top of it, for different distributions. That's why I see 
autodetection as a better alternative.

Another point on the topic of working on as many Linux distributions as 
possible: I have never taken any particular steps to make my binary 
releases distribution-independent (which is a somewhat delicate science 
- for more info, see the SDL mailing list archives, the topic comes up 
every now and then there, with links to articles on the web). I just 
build them on my Ubuntu or Fedora boxes, and if they work elsewhere, 
good, if not, people have to live with building from source. If anyone 
would like to spend some effort on this, that would be welcome.

In general, you would be welcome to take over maintenance of the Linux 
build system and the official binary releases. In that case I would give 
you free rein on the makefiles and stuff. I admit that I have been 
treating this with a somewhat reduced priority since Linux is not my 
main day-to-day OS.

  -Christian

Re: [Pipmak-Devel] Transition interrupts

[Urs H. <ur...@an...>]

Christian Walther wrote:
> Aidan Gauland wrote:
>>  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.
> 
> Thanks, this is committed (without extensive testing): rev. 180.

For the sake of completeness: This fixes the problem on my system and
doesn't seem to create any other problems.

Re: [Pipmak-Devel] Transition interrupts

[Urs H. <ur...@an...>]

Urs Holzer wrote:
> Christian Walther wrote:
>> Aidan Gauland wrote:
>>>  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.
>> 
>> Thanks, this is committed (without extensive testing): rev. 180.
> 
> For the sake of completeness: This fixes the problem on my system and
> doesn't seem to create any other problems.

However, I just found out that you should do the same thing for the open
dialog ;-)

Re: [Pipmak-Devel] Transition interrupts

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

Right!  I'll get on that.  :)

Urs Holzer wrote:
> Urs Holzer wrote:
>> Christian Walther wrote:
>>> Aidan Gauland wrote:
>>>>  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.
>>> Thanks, this is committed (without extensive testing): rev. 180.
>> For the sake of completeness: This fixes the problem on my system and
>> doesn't seem to create any other problems.
> 
> However, I just found out that you should do the same thing for the open
> dialog ;-)
> 
> 
> -------------------------------------------------------------------------
> 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
> 

Re: [Pipmak-Devel] Transition interrupts

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

  Ok, here's a patch to fix this.  I generated the patch from revision 180.

  Since you're using Linux, too, can you please test this?

  -Aidan

Aidan Gauland wrote:
> Right!  I'll get on that.  :)
> 
> Urs Holzer wrote:
>> Urs Holzer wrote:
>>> Christian Walther wrote:
>>>> Aidan Gauland wrote:
>>>>>  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.
>>>> Thanks, this is committed (without extensive testing): rev. 180.
>>> For the sake of completeness: This fixes the problem on my system and
>>> doesn't seem to create any other problems.
>> However, I just found out that you should do the same thing for the open
>> dialog ;-)
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
> 
> -------------------------------------------------------------------------
> 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
> 

Re: [Pipmak-Devel] Transition interrupts

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

Aidan Gauland wrote:
>  Ok, here's a patch to fix this.

Does that really fix it?? The warp you've inserted happens before the 
dialog is opened, not after, unlike in the save dialog case that you 
fixed in r180. (Just wondering, I haven't tested it.)

  -Christian

Re: [Pipmak-Devel] Transition interrupts

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

  I actually missed something when I was testing this: the bug only 
shows up if I move the mouse when clicking "Cancel".  And I made the 
erroneous  assumption that the openProject function opened a dialog at 
the same time as the saveGame dialog.

  Anyway, I think I did it properly this time.  Try the patch with this 
message.

  -Aidan

Christian Walther wrote:
> Aidan Gauland wrote:
>>  Ok, here's a patch to fix this.
> 
> Does that really fix it?? The warp you've inserted happens before the 
> dialog is opened, not after, unlike in the save dialog case that you 
> fixed in r180. (Just wondering, I haven't tested it.)
> 
>   -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
>