I apologize for the general silence over the last few months. Unfortunately, life has been too busy to do much coding for Grotesque. Things have cleared up, so now I’m ready to get back to it. I’ve decided to start blogging the development process so people can have some sign of life in the project.

With the next beta release, version 0.9.4, in mind, I’m mainly looking at structural changes “under the hood”, in order to stabilize things a bit and to facilitate the future addition of new features.

First of all, I had been maintaining two separate branches of the code to support both GTK 2 and GTK 3. This was insane and unmanageable, plus it had the side effect of making the user choose which version to download. I’ve rearranged the code so that both versions are in the same branch, which allows easier parallel changes, but the choice of which to use is made by the program itself. It’s still tough to try to maintain code for both library versions, and I still intend to stop developing for GTK 2 once we hit 1.0. It’s for my own sanity.

What I’m working on now is a brief aside. Grotesque comes with a pure Python implementation of the Treaty of Babel. I’ve decided that this is pretty useful, and others should have access to the library as well. So, I’m splitting off development of that library to a separate project. I’ll update the code a bit to more closely resemble the official C API for the Treaty. There’s also some code that is embedded in Grotesque which would be more appropriate in the Treaty library, so I’ll move that over as well. This will all involve a few changes in the Grotesque code. For Linux users, this means that the new Python Treaty of Babel module will have to be installed separately. I’ll make this as easy as possible by putting it in PyPi and I’ll at least add it to the Arch Linux AUR, with the hopes that others will package it for other distros.

Next will be the big change for 0.9.4, which will be migrating from a basic Python- pickled flat file for storing user data to storing everything in an SQL database. The original method made sense at first, when each story was only stored with its basic Treaty metadata. Now that I’m adding new things like played state and contemplating adding things like tags, notes, etc., I’m finding that it’s becoming difficult to manage. An SQL database will help with that, though it does increase the complexity of the program. Also, for Linux users, it will add more dependencies (namely SQLAlchemy and Elixir).

Well, that’s it for now. I’m looking forward to getting 0.9.4 out there, since it’s been a long time since an update!