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
>