Right now there are three major tasks to attack:
Full implementation of special commands
Currently, as you will have seen in the demo, users can write things like special::clear or special::deleteword in the link field of the PowerPoint template to give the buttons special behavior. At the moment, only those two commands are implemented, and there are many left to do – the commands to insert different text than the label, or control external functions (like TV controls and the calculator).
Export to the open board format
We are big fans of the Open Board Format around here, and it’s a bit embarrassing that we haven’t put the code in to get us there. Currently our parser takes in a PowerPoint document and produces a JSON file and some icons. It should be trivial to extend this so that it plays nicely with the other Open Board Format tools and, from a wider perspective, it’s important to get this done before ISAAC – it will be a tricky sell to talk about the importance of portability and all the advantages of open source if we haven’t got on board with the format.
The third, and deeply unsexy thing we need to put in place is an automated testing core. For the uninitiated: we need a script that runs AzuleJoe on a range of different inputs designed to test the limits of the code. This helps us check that a new feature hasn’t broken an old one and means that we can also start doing significant rewriting of the code to make it a little more efficient and easier to maintain.
When I started writing this post I thought that getting the special commands working was going to be the thing to tick off (because then I could call the current state of the code a stable release) and then we’d look at everything else. However, the more I wrote, the clearer it was to me that the testing structure is going to have to happen first. I’ve been running into more and more development problems around pageset versions working one day and failing to work another and that’s causing problems.
More to the point, without a sensible test architecture, it’s very hard for other people to work on the code well. Now that we’ve got people using the code in Academia, it’s going to be hard to encourage them to merge changes back into the trunk without a proper test system.
So it looks like I’m going to have to finally work out how testing works in Python. Time to go into research mode.