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!