Archive

We haven’t made a lot of progress due to the whole development team having finals, but we have several showstopper bugs, to the point where our program really isn’t useful. Most of the problems stem from integration issues between code written by different people. While I’m working through some of these issues I thought I’d document our backend architecture here to make sure I understand it completely, to give some insight into our program, and maybe get some feedback on our design. I try to keep it as high-level as possible, but it does get a bit technical.

First, some background. We have a class, BackendManager, which is the overall manager of conversions. Inside BackendManager, we have two main abstractions, Converter and Conversion.

Converter is a standard interface to your various converters. It abstracts away all the specifics of the individual programs. It provides a list of supported input and output formats, and all the configuration is setting the input and output formats to use, checking that a valid configuration was possible, and executing with input and output files.

Conversion is a container class, with an input filename, an output filename, a pointer to the Converter to use, and a pointer to the next Conversion for when multiple converting steps are required.
At program startup, a BackendManager object is created. It is then given a directory of XML files, from which it builds the global set of Converters. The actual building of the file is handled by the Converter, so BackendManager just has to iterate through the files and create a Converter object for each one, feeding it the filename of the XML file. It then builds a hash table of valid single-step conversions from all the loaded Converters.

The program can query BackendManager for the supported input and output formats, and additional can check if an output format is supported for a given input. Currently it only checks single stage conversions, but that is on the todo list to resolve.
The program can also request a conversion be setup for a given set of inputs and outputs. It is returned a Conversion pointer.
It can then give these Conversion pointers to BackendManager when an actual conversion is to be performed. We plan to refactor so that external code doesn’t need to know about the Conversions at all later. Each Conversion pointer is assumed to be independent of the others, with dependent Conversions indirectly passed by the pointer for the purpose within Conversion. BackendManager then kicks off a conversion process in a separate thread with ConversionExecutor. ConversionExecutor creates new threads for each Conversion using ConversionStarter, up to the maximum number of concurrent threads, currently hardcoded to 5. Once 5 threads are running, it waits for one to finish, and then starts another as each does until it runs out of Conversions to run.

That’s our program’s backend, more or less. The current bugs considered showstoppers are that our program has:

called the wrong converter

not configured a converter

lost conversion steps

crashed instead of converting

As soon as these are straightened out such that our program actually converts as it is asked, at least most of the time, we will get a release out.

We are working very hard tonight to get an alpha release out. We have the program running and compiling for windows we’re just scrambling to hook up the rest of the dynamic GUI features for first release. If you’re dying to see it, there’s a temporary build system in place for windows:

1) Make sure you have Boost threads and filesystem libraries (instructions for how to install them in windows on /docs) and Qt libraries installed. You also will need Code::Blocks.

2) Pull the repository and open /src/unibatchconv.cbp (this is a codeblocks project)

3) You should be able to build it and run it. If you get problems with not being able to find boost or qt stuff, you must open Build Options and change your search directories and linker settings to point to your boost thread/filesystem and qt libraries.

Note: This is our development build system. Our deployment will use CMake, which isn’t working yet.

Alpha Teaser (Windows)

So if you do get it to build and run in windows, you will get the following:

Click to enlarge.

To Do
– Make category tabs be created dynamically
– Implement advanced options for converters dynamically (The backend architecture for it is written but the GUI doesn’t use it yet)
– As always, right more XML for new converters (next up is documents; we support audio and images now)
– The Add button in the picture will probably be moved to the right of the Remove button since it looks very out of place where it is (The original idea was to make it be clear what you’re adding to)