Quantcast

[Pipmak-Devel] Transition interrupts

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Pipmak-Devel] Transition interrupts

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

transitionInterrupts.patch.gz (596 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

Aidan Gauland
  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
> [hidden email]
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
>

dialogCloseGrab.patch.gz (401 bytes) Download Attachment
transInterrupts.patch.gz (1K) Download Attachment
MakefileLinux_libPaths.patch.gz (900 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

Aidan Gauland
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
> [hidden email]
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

Aidan Gauland
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
> [hidden email]
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

Aidan Gauland
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
>> [hidden email]
>> 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
> [hidden email]
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
>

transInterrupts.patch.gz (729 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

Urs Holzer-2
In reply to this post by cwalther
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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

Urs Holzer-2
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 ;-)



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

Aidan Gauland
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
> [hidden email]
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

cwalther
Administrator
In reply to this post by Aidan Gauland
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

Aidan Gauland
In reply to this post by Aidan Gauland
  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
>> [hidden email]
>> 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
> [hidden email]
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
>

openDialogGrab.patch.gz (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pipmak-Devel] Transition interrupts

Aidan Gauland
  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
> [hidden email]
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
>

openDialogGrab2.patch.gz (425 bytes) Download Attachment
Loading...