Controlling Rhythmbox with your Wiimote

I've been fiddling with one of my Wiimotes tonight to try and get it to control Rhythmbox. Turns out it's actually really easy! You can do it via the cwiid library for Python, and with a Rhythmbox plugin.

For this to work, you need a Wiimote and some sort of Bluetooth device for your computer that works with Ubuntu. You'll also need the correct package:

sudo apt-get install python-cwiid

Here's the step-by-step guide to getting it to work:

1. Create a folder at ~/.gnome2/rhythmbox/plugins if it doesn't already exist.
Create a file in there called WiimoteControl.rb-plugin, and put the following in it:

[RB Plugin]
Loader=python
Module=WiimoteControl
IAge=1
Name=Wiimote Control
Description=A way to control Rhythmbox with your Wiimote
Authors=Rob Britton 
Copyright=Copyright (c) 2011 Rob Britton
Website=http://lovehateubuntu.blogspot.com/

You can replace my name with yours if you want, I won't mind ;)
2. Create a file called __init__.py, and put the following in it:

   import rb
   import cwiid
   
   rbshell = None
   
   def callback(mesg_list, time):
     # Called whenever a button is pushed on the Wiimote
     global rbshell
     for mesg in mesg_list:
       if mesg[0] == cwiid.MESG_BTN:
         if mesg[1] == cwiid.BTN_A:
           rbshell.props.shell_player.playpause()
         if mesg[1] == cwiid.BTN_LEFT:
           rbshell.props.shell_player.do_previous()
         if mesg[1] == cwiid.BTN_RIGHT:
           rbshell.props.shell_player.do_next()
   
   
   class WiimoteControlPlugin (rb.Plugin):
     def __init__(self):
       rb.Plugin.__init__(self)
   
     def activate(self, shell):
       # called when Rhythmbox starts
       global rbshell, bus
       self.shell = shell
       rbshell = self.shell
       self.wiimote = None
   
       print "looking for wiimote..."
       self.wiimote = cwiid.Wiimote()
   
       print "found wiimote"
       self.wiimote.enable(cwiid.FLAG_MESG_IFC)
       self.wiimote.mesg_callback = callback
       self.wiimote.rpt_mode = cwiid.RPT_BTN
   
     def deactivate(self, shell):
       # called when Rhythmbox closes
       self.wiimote.close()

   This code sets up the Wiimote and binds left/right to previous/next song, and the A button to Play/Pause.
3. Open Rhythmbox, and while it is opening push the 1 and 2 buttons on the Wiimote. It will take a sec for Rhythmbox to open since it is looking for the Wiimote.

All this should make it so that your Wiimote can connect and control Rhythmbox. To get debug messages, you can run Rhythmbox from the command line:

rhythmbox -D WiimoteControl

The program isn't ideal, since if you don't connect the Wiimote in time it will not properly set everything. It might be better to put some sort of timer that goes periodically to check to see if the Wiimote is there and if it is not, attempts to connect it. Also I think it would be neat to be able to control the volume using the up and down buttons, but I'm not quite sure how to do that yet. It doesn't seem to be in the Rhythmbox plugin guide, and the other plugins don't really do that sort of thing.

Adventures in Python

Although over the last few years I've dabbled in Python a little, I've never really sat down and made an actual program with it. I made a little web app for Google's app engine some time ago, however I don't really consider it a lot of coding and hardly enough experience to say that I really know the language.

I have the same problem that most Ruby people seem to have: we really see no reason to learn Python. There is not really any objective benefit that it gives. Both Ruby and Python offer faster development times compared to languages like C++ or Java (although it would be interesting to see which of the two languages would be faster, I don't really know). They're both interpreted (and therefore, slow and memory-intensive). They both have good-sized followings and plenty of free software available for them. So I don't really know any good reason to switch between the two - I know many Python people say the same about Ruby.

For the record, the thing I'm making now is a little game. You can check it out here if you like, it is a little Diablo-style game where you go around stabbing monsters. Hopefully it will evolve into something cooler at some point, but for now it is pretty limited.

Anyway I'll give my first impressions of the language, from the perspective of someone who has lots of experience with other Perl-derived languages (namely Ruby and PHP). Keep in mind that this is all subjective and you are more than welcome to disagree - although I think most of the people who read this blog are Ruby people anyway so I doubt too many feelings will be hurt by this one.

Things I like so far:

• Whitespace - I love it. At first I felt as though my code were naked without end keywords or closing brackets, however after a while it becomes enjoyable. I find it makes the code much more clean, and you don't have to worry about whether you have too many or too few ends, just make the indentation work (which I would have done anyway). I do tend to forget to put the colon at the end, but that's probably just because I'm still new to the game.
• Modularity - At it was a little annoying to have to import the modules in every single file that use it or to have to specify "from ... import ...", but in the long run it is a better way to go in that it helps break down coupling between files. I'm thinking I should take this back to Ruby and design things in this way.
• List Comprehensions - they're nice and precise and do things that in Ruby you'd have to use zips, maps and selects for (unless of course my Ruby-fu is not amazing and there are similar things in Ruby that I don't know about, which is likely).

Now for the things I don't like:

• Object-Orientation - it feels a little...clunky. I have to put self everywhere. While it isn't a real complaint, it is a bit annoying and does clutter things up a fair bit. I find Ruby's sigil notation to be cleaner. Also one of the things from PHP that I really hated was having to declare something as global, it is here too. Don't like it.
  static vs. class methods? Not sure why. It also seems like I have to jump through hoops to create these things.
• Naming conventions: __ clutters up the screen, I feel like I'm writing C again: typedef struct _name { ...
  I find def+() or operator+() to be much more readable. But then again, it's what I'm used to.
  Finally, certain things like lists not having a length() method and instead you call the global method len() seems to be a little inconsistent to me. Same goes for various things like map, filter, etc.
• It's very imperative - This may not be a bad thing. Some people like this kind of programming, they say it's old school. Feels like real programming again instead of plugging libraries/gems into one another and suddenly having an application.
  For me, I've gotten used to using functional-esque programming with Ruby and to a lesser extent Javascript with jQuery, so coming to Python seems like I'm more limited in how I can express what I want to write. But whatever.

So yeah, my reasons for it aren't really substantial, nor are the reasons against it. What do other people think?

One thing I've really learned here is that I haven't really done much with Ruby besides web apps, which in terms of complexity really aren't that deep - I don't know if "deep" is the right word here, but it seems like that when you write a web app there are fewer levels of moving parts than in an app like a game. I wonder what it would be like if I rewrote this app in Ruby, if it would have taken as long to make and if it would be more maintainable or not - probably yes since I actually know Ruby a lot better, but maybe not.

pygame

In my latest project I've been messing around with pygame, which is a Python wrapper and extension for the SDL media library. It is great because it adds all sorts of object-oriented stuff on top of the original SDL functionality, without really sacrificing anything (at least as far as I've noticed).

You may wonder why I chose Python for writing a game over C or C++. Well to be honest, it was mainly just to learn Python, and Python just so happened to have this gaming library available. However the more I use it, I think it might actually be a viable strategy for simpler games. If something somewhere is going too slow or using too much memory, you can always just write a part in C++ using Boost.Python and import it in - I'll be honest, I haven't tried Boost.Python so I don't know if it is as seamless as they claim, there could be more on this later.
Python offers much faster development time over C++, I noticed this right away. I can add things very easily that weren't originally in the plan. If I have a bunch of classes with similar functionality, I can quickly refactor them to inherit from a base class which provides the shared functionality - while I can probably do this in C++ too, I'd have to go through the code everywhere and use references/pointers to base class objects instead of the original - bit of a pain.

You may also now wonder why I didn't write it in Ruby. Well, like I said, wanted to learn Python. At this point, I still want to learn Python - I haven't been turned off it yet like I was with Haskell or Scala either (not sure why I was turned off of these, maybe because I'm too dumb or entrenched in my ways to really grasp their more advanced concepts). Also, Ruby is nice and all, but it's what I use at work. I'm happy about that, I'd rather be doing Ruby than PHP or Java, but I'd like a little bit of change when I go home and do my own coding. Choosing another language helps satisfy that desire for change.

Google's App Engine

I don't know how long this has been around, but I've recently discovered Google's App Engine, which is a free hosted web application system. It's funny, because just the other day I was thinking of creating a small web app for playing a simple game and was wondering, "Where would I host this?" I could use freegamage.com, but since that project has mostly been a failure I doubt I will be renewing the domain.

This is pretty neat. You get 500MB of storage for your app, not sure if this includes databases but most likely. If all you're doing is a basic app with a few images here and there, this is easily enough. You also get enough bandwidth to handle approximately 5 million hits per month. That's more than I'd need for any site I'd make on my own time, and if I was getting 5 million hits per month I'd probably be able to make enough through advertising to host my own site somewhere else.

To use it, you just download a copy of the Google App Engine SDK and extract it. Voila, you have a rudimentary web app! It comes with a basic web server and database, so you don't even need to install anything - except Python, but if you're on Ubuntu it comes with Python anyway. On other platforms it's fairly simple to install Python, just download and run the installer. There are a bunch of scripts too that handle updating the framework to a newer version, uploading your app, etc. And all you need is your Google account.

You get access to Google's webapp framework. This is a simple Python framework that gives you basically everything you need to create a web application, including templating and database support. They say they will be releasing a version for other languages soon, but Python is a good language and I'm more than happy to be using it (this also gives me an excuse to learn Python).
After exposure to Smarty, I decided that I hated templating engines (I don't really consider eRuby a templating engine). However, after making a framework of my own, I thought that maybe a templating engine isn't such a bad thing - especially where efficiency comes in. The webapp framework uses a simple templating engine (same one as Django) that ties in rather well with what you're doing. So no complaints here.

An excellent addition to this is that it ties into Google's user network. If you are making an application that requires authentication, you just use the user's Google account. Since most people have one of these already (and those that don't should have one, Gmail alone is worth it) you don't need to keep track of users and all that. You don't need to write the "forgot password" section, since Google has taken care of that already.

One interesting thing is that they don't use SQL for their database. It's not even a relational database. In fact, they don't even call it a database, it is called a datastore. I'm not really certain how it works internally, but it says it uses "Google's scalable infrastructure", which is good enough for me! The framework provides a little query engine for the database that uses GQL, an SQL-like language. It seems to be a bit more object-oriented than SQL, as instead of rows, the queries return objects. Again, I'm not sure how this all works internally, but I don't really care at this point.

On Python: It's neat. I've used Python here and there in the past, learned the syntax and all that, but this is a bit more in-depth and I'm learning some of the differences between Python and Ruby. Of course, the more annoying aspects are the ones you notice: having to put self in the parameter list for every method, and I always forget to put a colon at the end of block things like if/else.
What do I like? It's hard to find things that I like about it, I haven't really done enough to go "oh, that's neat!" I do like tuples, something that I missed when going from C++ to Ruby (C++ doesn't have tuples, but I liked using std::pair). Python makes this kind of thing fairly elegant compared to C++.
I don't really have any comments on the indentation style of Python. It would probably be annoying if I didn't already indent like Python wants you to. The only difference is not putting the end keyword or closing curly brace, which does tend to make code cleaner and eliminates the annoying syntax errors of "expecting kEND, found $end" or "unexpected end-of-file".
Syntaxes aside, in the Ruby vs. Python debate I would probably say neither is better, they just adopt different philosophies (Python's one-way-to-do-it vs. Ruby's you-can-do-whatever-you-want). And unless you're an advocate of one of these, I suspect that the language you like better is the one you pick up first.

So yeah, I would recommend you check this one out if you're a web developer. It will probably make your life easier, at least if you have a cool idea that you want to try out.