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
>