[Mirra] Mirra and pygame

[enrike]

hi

which version are you running? are you using the svn or the latest 
stable 0.3.1? Because of the issues you are talking about I think you 
have the svn one. I checked and the 0.3.1 still keeps the pygame 
compatibility. In the svn version I removed pygame support but i am 
considering putting it back, there are certain things I cannot get right 
only with wxPython (gamepad support, importing images), I mean in some 
cases it might be better to run under pygame. In that case 
03eventskeys.py would be valid again otherwise I must update to 
wxpython, but I am almost convinced that I should put pygame back.

The svn version is sometimes pretty experimental, I try many things out 
and at some points it becomes a bit unstable, I think I need to say this 
next to the link to the svn version.

About exiting the App, you mean you want to have a function that quits 
the App loop?, it is of course a good and basic idea, I can see in my 
code I never thought about it before. Great that you are pointing into 
it! I guess we need a function in App like close() that would implement 
in WxWindow and PygameWindow the right way to exit the main loop.

In the version you are running we need to call Close() method in the 
Frame in the Window so from the App we would need to do
self.window.frame.Close(True)
that quits the App and calls the end() method before exiting.
Close() is a method from WxPython Frame class.

In pygame we would need to have a variable in the main loop
while self.running :
	blah
setting self.running to False would exit the main loop

I agree that it would be nicer to have a method in App that does the job 
something like self.close() from the App. This way the wxPython/pygame 
code would stay in a deeper layer.

You might want to check this applications i have developed using mirra, 
they might clarify (i hope) some points.
http://www.ixi-software.net/content/download/slicer/slicer0.1.zip
https://devel.goto10.org/dl.php?repname=ixi&path=%2Fpython%2Fcircles%2F&rev=0&isdir=1

once again, many thanks for your comments, it is really useful to get 
feedback like this, it forces to face problems and situation I might not 
see by myself otherwise.

enrike




dropmeaword at yahoo.com(e)k dio:
> Enrike,
> 
> I have also noticed that importing pygame.locals for the key constants has no effect whatsoever because the window manager in Mirra 0.3.1 is no longer pygame, but wxPython, which means that the key constants in pygame are not the same as the ones passed as params to the event callback keyDown, if you check for K_q then run and press 'q', the program doesn't match it.
> 
> The example 03eventskeys.py is no longer valid, the key constants K_xxx are not used in the latest version of WxWindow (wxPython as window manager).
> 
> I have a question, is there any way to exit main.App cleanly? Pressing ALT+F4 closes the window and seems to close the application appropriately, but if I want the application to exit cleanly after a certain condition has been met, there's no obvious way of doing it.
> 
> I have tried adding a method to the WxWindow(wx.App) type:
> 
>         def close():
>           self.frame.close()
> 
> and the following method to the main.App type:
> 
>     def exit(self):
>       self.window.close()
> 
> but wxPython doesn't like it. I get this error message:
> 
>   File "E:\Downloads\Development\python\interaction\mirra\examples\mirra\main.py
> ", line 260, in OnPaint
>     self.app.step() # call subclass step method
>   File "snow.py", line 51, in step
>     if self.quit == True: self.exit()
>   File "E:\Downloads\Development\python\interaction\mirra\examples\mirra\main.py
> ", line 411, in exit
>     self.window.close()
> TypeError: close() takes no arguments (1 given)
> 
> I would like to be able to do something like this in my App class:
> 
>     def step(self):
>       if self.quit == True: self.exit()
> 
> if condition is met, exit. Simple. :)
> 
>> BTW, you know that there is the possibility to choose between pygame and 
>> wxpython to manage the window, I have been considering dropping pygame 
>> mostly because I use wxPython most of the time and having both means 
>> duplicated classes in main and events modules. It would be good to hear 
>> whats your opinion about this.
> 
> I didn't know the choice was possible, in fact looking at main.py it seems that the code for the
> pygame based window is commented out, so the API doesn't allow you to choose. Of course it would be great to be able to choose window manager when creating the window, something like:
> 
> win = factoryWindow(WXPYTHON) or win = factoryWindow(PYGAME)
> 
> but the reason why I like Mirra is because it's simple, it's not a generic abstraction layer, but a simple
> wrapper. I think wxPython is more flexible as it allows someone that wants to use other wxPython widgets in the window to do so.
> 
> For some reason, I'm still stuck with an incredibly low performance. My test Mirra apps barely peak at 10 fps, I have tried profiling them with hotshot, but I'm having a hard time interpreting the output. Much of the time is spent in:
> 
> graphics.py(render)
> utilities.py(getRect)
> graphics.py(getZ)
> 
> I've looked at the code and I see nothing abnormal. I don't understand why getRect should take that long. I fear that the opengl canvas is not hardware accelerated, for some reason it seems to be rendering by software, it definitely is as slow as if it was. I'm just speculating though, as I haven't had the time to dig further into it.
> 
> I also found this lib, Devachan: http://www.cesaremarilungo.com/sw/devachan/
> That offers a proce55ing-like wrapper for python that runs pretty fast (it's a C extension). I'd rather stick to Mirra though as I find it easier to extend and fool around with. But performance has me worried.
> 
> Cheers,
> Luis.
> 
> 
> 
> ----- Original Message ----
> From: enrike <enrike at ixi-audio.net>
> To: dropmeaword at yahoo.com
> Cc: mirra at goto10.org
> Sent: Thursday, May 17, 2007 11:07:43 AM
> Subject: Re: [Mirra] Mirra and pygame
> 
> hi
> 
> you are right ... I was using pygame.locals in an app but I was 
> importing it locally in a function so i did not get any error, the 
> conflict is with color argument used in most classes from graphics 
> module that is already defined in pygame.locals
> 
> thanks for reporting this! i am going to check if there is some way to 
> solve it maintaining the
> from mirra.graphics import *
> because i think it is handy to use directly Rect, Circle and not 
> graphics.Rect, etc ... but your solution might be the cleanest.
> 
> BTW, you know that there is the possibility to choose between pygame and 
> wxpython to manage the window, I have been considering dropping pygame 
> mostly because I use wxPython most of the time and having both means 
> duplicated classes in main and events modules. It would be good to hear 
> whats your opinion about this.
> 
> thanks
> 
> enrike
> 
> 
> dropmeaword at yahoo.com(e)k dio:
>> Hello,
>>
>> Seems like importing pygame.local overrides the Mirra graphics namespace. The following is a short example that works ok:
>>
>> #!/usr/bin/env python
>>
>> from mirra import main
>> from mirra.graphics import *
>> from mirra import utilities
>>
>> class MirraApp(main.App):
>>     def setUp(self):
>>         self.caption = "namespace sample"
>>         self.size = 640, 480
>>         self.pos = 100,100
>>         self.fullScreen = 0
>>         self.frameRate = 15
>>
>>     def start(self):
>>         self.txtdisplay = Text('some text', 300, 300, 1)
>>         
>>         for z in range(150):
>>             x = utilities.randint(0, self.width)
>>             y = utilities.randint(-150, 0) 
>>             d = utilities.randint(5,10)
>>             Particle(x,y,z,d,d,color=(1,0,0,d))
>>
>> class WeeSquare(Rect):
>>     
>>     def step(self):
>>         self.y = 120
>>         self.x = 120
>>
>>
>> if __name__ == '__main__': MirraApp()
>>
>>
>>
>> adding the import statement:
>>
>> from pygame.locals import *
>>
>> breaks the example, causing namespace conflicts. This is the error message you get at runtime:
>>
>> Traceback (most recent call last):
>>   File "E:\DOWNLO~1\DEVELO~1\python\INTERA~1\mirra\examples\mirra\main.py", line
>>  259, in OnPaint
>>     if not self.init: self.initFrameRate()
>>   File "E:\DOWNLO~1\DEVELO~1\python\INTERA~1\mirra\examples\mirra\main.py", line
>>  215, in initFrameRate
>>     self.app.start() # call start subclass method just before entering the main
>> loop, to initialise objects etc...
>>   File "sam1.py", line 24, in start
>>     Particle(x,y,z,d,d,color=(1,0,0,d))
>> TypeError: Argument must be rect style object
>>
>> Given that the key constants are in pygame.locals it's a pretty frequent import you are bound to use sooner or later. It's unfortunate that it breaks the mirra.graphics namespace. Both Rect and Text are defined in pygame.
>>
>> Changing the mirra.graphics import to
>>
>> from mirra import *
>>
>> And preceding the class names with the namespace where they belong solves the problem 
>>
>> class WeeSquare(graphics.Rect):
>>
>> instead of
>>
>> class WeeSquare(Rect):
>>
>>
>> but imho it's an inconvenience.
>>
>> Cheers,
>> Luis.
>>
>>
>>
>>
>>
>>
>>
>>
>>  
>> ____________________________________________________________________________________
>> Need Mail bonding?
>> Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
>> http://answers.yahoo.com/dir/?link=list&sid=396546091
>>
>> _______________________________________________
>> Mirra mailing list
>> Mirra at goto10.org
>> http://lists.goto10.org/cgi-bin/mailman/listinfo/mirra
>>
> 
> 
> 
> 
> 
> 
>        
> ____________________________________________________________________________________Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
> http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  
>