There’s a new version of Beru available all over (more on that in a bit) that tries to make Beru more usable on the desktop. In a way, this goes make to my original goal in developing Beru: to make a better Epub reader to use on my computer. I’d tried a few and didn’t like any of them. They didn’t paginate, or they insisted on managing your files for you, or they lived in your browser, or they were annoying in some other way. I wanted to build a basic reader that integrated well into Ubuntu and didn’t try to call attention to itself.
So when the new Ubuntu SDK was announced, I figured I could build Beru with that, using it as a chance to learn the SDK at the same time. As I learned, the SDK was (and still largely is) focused on touch devices, so the app that resulted wasn’t particularly suited for use on the desktop. Nonetheless, I’m using it on the desktop (in fact, I still don’t have a touch device), so I’ve been adding bits and pieces to improve my experience. Now it’s time to share.
The biggest problem was that of application confinement. Apps distributed through the click store cannot access the file system outside of their own little silo. Thus, earlier versions of Beru could only access Epub files stored within their own special little directory. Perhaps this is acceptible on a phone or tablet, where users aren’t used to managing their files, but this is intolerable on the desktop. Applications should work with the user’s file layout; they shouldn’t force the user to move files around. I should be able to tell Beru where to find Epubs, instead of being forced to store all my books in .local/share/com.ubuntu.developer.rschroll.beru/Books/! For a while, I was maintaining two branches, with and without these restrictions, but I couldn’t keep that up.
Instead, I realized that an existing bug held the solution: the default location for books should be a setting. When we’re free, the user can set that to be whatever she likes. When we’re constrained, we set it to that monstrosity of a path above.
Actually finding out whether we’re under confinement is another pain. QFileInfo.isWritable() will happily tell you that you can write to a directory, but writes to the directory will silently fail, blocked by AppArmor. I ended up using the try and fail approach. It seems silly, so I’d be glad to hear if there’s a better way.
Obviously, the Ubuntu SDK is very touch-focused at this time, so keyboard control of apps is lacking. I’ve taken the first steps towards resolving this by adding keyboard control of page turns. (Space, right, down, or period to advance; Backspace, left, up, or comma to reverse.) Adding keyboard shortcuts for the toolbar items would be an obvious next step, but I’m waiting to hear if there’s any official guidance on that first.
A problem I was not expecting is that the SDK differs between Ubuntu releases on the desktop. Not intentionally, mind you, but they haven’t been able to build a version of the SDK for Precise, Quantal, or Raring since early October. The public interfaces apparently haven’t changed in that time, but some things require access to private interfaces, which have changed. Anyway, Beru now ships with it’s own version of OptionSelector, since it can’t trust the system to provide the right version.
Finally, we need a way to distribute Beru to desktop users, since the click store is only available to touch users. While you can install click packages on the desktop, the process is somewhere between awkward and broken. A better way is to provide debs in a PPA. I’d never build deb files from scratch before, so this was a bit of an adventure. Like most documentation, the debian packaging documentation seems designed for people who already know what’s going on. This post contained a bunch of info on building debs for a Ubuntu SDK app. The section on the debian/ directory was most helpful. (Hint: If you’re planning on uploading to a PPA, change Section: unknown in your debian/control file to something else. I chose Section: misc.) The section on actually building the packages was a bit thin and assumes that you are using bzr and launchpad. Eventually I managed to build a source package by using git archive to make the .orig.tar.gz file from HEAD, untarring that somewhere else, and running debuild -S to create the source package. This script in the debian branch contains the gory details.
Once you’ve build the source package, you can use pbuilder to test that it builds in a clean environment. That post had instructions, but make sure to use the ~/.pbuilderrc they provide—it’s the thing that gives you the correct release. Once it builds, you’ll get the resultant deb file in /var/cache/pbuilder/$RELEASE-$ARCH/result/, which is apparently so obvious that it isn’t documented anywhere. (The man page helpfully points to another path.)
Once you upload a source package to Launchpad, it decides for which release it will be build based on the latest entry in the debian/changelog file. I couldn’t find any way to tell it to build for multiple releases. (You can tell it to copy the source over to another release, but then both sources try to build debs with the same name. Then they start sending you emails telling you that you’re trying to overwrite existing files.) Instead, I follow Robert Ancell’s advice and upload a different source package for each release. It seems like a waste, but I’ve already wasted enough time trying to figure out this packaging system.
Anyway, the point of all the rambling is that Beru is now available in ppa:rschroll/beru. Enjoy!