Re: [pygame] Wiimote and I/O Questions

[Luke Paireepinart <rabidpoobear@xxxxxxxxx>]

René Dudfield wrote:
> Hi,
Hey, thanks for the responses, Rene and Alex.
> > So, finally, I get to my questions:
> > 1. Is it really so bad to just have it run in a thread and use
> > forever-blocking file reads (do these use a lot of the CPU?)
>
>
> I think a thread is best here.  Then just post events into the pygame
> event queue.
>
> Before anyone cries out 'but threads are EVIL! and hard to use!!!!',
> users won't see this thread.  It will just post events into the event
> queue.
>
> A thread has the advantage that it can run at a separate frequency
> from the users main loop.
Personally, I think a thread is a good idea here too.
But I don't know every possible implication, and if someone had a really 
good argument against a thread,
I would've tried to find an alternate way to do it.

Someone suggested that I keep the pygame-specific stuff decoupled from 
the actual wiimote stuff so that it can be used
with other toolkits.
My idea in doing this is to have my wiimote class have a method called 
"postEvent" that my update method calls whenever there's a change of state.

class wiimote(object):
  def update(self):
     ...do stuff...
     for each in changedAttributes:
         self.postEvent(each)

  def postEvent(self,stuffThatChanged):
     ... create Pygame event for stuff that changed, post it to the 
event queue...

something like that.

the call to postEvent would indicate which attribute of the wiimote had 
changed (button press / accelerometer data/ etc)
but it'd be up to the postEvent class to translate that into the proper 
event structure and post it to the event queue.
That way, if anyone wanted to use the library for any other toolkit, 
they could make a class which inherits from wiimote
and override just the postEvent function, adding in whatever 
functionality they need for the task.
They could even just override postEvent with a null function and read 
the attributes of the wiimote class instances directly,
whenever they needed to access the data.  but then they'd potentially 
lose some data.
I guess, technically, they could just overwrite the self.postEvent 
method for an already-defined instance too...
def f(unusedArgument):
  print "Hello, world!"
wiimoteInstance.postEvent = f
couldn't they?
That's bad practice, though, unless necessary, correct?


Well, all the other ideas I've come up with seem far less elegant than 
this one.
Does anyone have a better way to do this?

> > 2. Does anyone know of a windows dll command that will read from a file
> > with a timeout?
>
> Not needed if you use a thread.
Yeah, that's an advantage.

-Luke