Entangle at LibreGraphicsMeeting 2014, plugin system and Windows porting
Libre Graphics Meeting, 2014
Last week I took some time off from my day job working on virtualization, to travel to Leipzig for this years LibreGraphicsMeeting. This was my first visit to LGM, coming about after Jehan Pagès suggested that I present a talk about Entangle in order to attract more developer & user interest. I had a 20 minute slot at the end of the first day where I went through the basic concepts / motivation behind the project, then did a short live demo, finishing up with a look at some of the problems facing / future needs of the project. Historically my talks have always involved death-by-bullet-point style libreoffice slides, but for LGM I decided it was time to up my game. So I turned to the GNOME Pinpoint application:
“a simple presentation tool that hopes to avoid audience death by bullet point and instead encourage presentations containing beautiful images and small amounts of concise text in slides”
I took this to heart, creating a set of slides which consisted entirely of beautiful images I’ve taken myself overlaid with just one or two words of text. I found it quite a liberating experience to give a presentation using such a slide deck, since it freed me from having to read the slides myself or worry that I’d forgotten to talk about a particular bullet point. Hopefully those in the audience found the talk a more fluid & engaging experience as a result. After the talk, and in the days following, I had interesting discussions about Entangle with a number of other attendees, so going to LGM definitely achieved the goal of attracting more interest.
At the end of the last day, we had the usual conference group photo, but Jakub Steiner then raised the bar by getting out his quad-copter with camera mounted to shoot a group video from the air.
Application plugins
Since the very start of the project, it has always been the intention for users to be able to extend the core interface with custom plugins. Thus far though, this has been all talk, with little real action. Entangle is written using GTK/GObject with a fairly well structured object hierarchy / codebase to make it easier to understand / extend and integrates with the libpeas library for plugin infrastructure. What has been missing is proper annotations on the internal APIs to enable GObject Introspection to be able to correctly call them from non-C languages. The past few weeks I’ve been working hard to address all the warnings displayed by g-ir-scanner with the goal that all internal APIs are fully annotated with calling conventions.
I had tentatively setup libpeas to use the ‘gjs’ loader to enable plugins to be written in JavaScript, inspired by the fact that GNOME Shell is extendable using JavaScript. At LGM, Martin Owens (IIRC) mentioned in passing to me that he thought Entangle would be better off using Python. Though we didn’t get into a deep discussion on this matter at the time, it got me thinking about whether JavaScript was the right choice. A few months back I did start hacking on a GNOME Shell extension for displaying an astronomy weather forecast in the top bar, which naturally enough was in JavaScript. One of the frustrating things I found with that effort was a general lack of documentation / examples about JavaScript usage in the context of non-browser apps, as well as the lack of a good archive of reusable library functions. While the GNOME platform APIs are, of course, all available for usage, there’s more to the world than GNOME. In particular I needed code for calculating sunset/sunrise times and lunar phases. With this experience in mind, and since there are no plugins yet written for Entangle, I’ve decided to switch it to use Python for its plugin system. This means that as well as having access to the GNOME platform APIs, plugin authors will be able to leverage the entire Python ecosystem which is truly enormous. Since Entangle requires GTK3, which is pretty modern, I decided I might as well ignore Python 2.x, so Entangle is going to require Python 3 only. This avoids a painful decision later about whether/when to switch from 2 to 3.
To actually prove that the plugin system is useful, I’ve also started work on a simple demonstration plugin. The goal of the plugin is to provide a way to turn the UI into a capture “selfie” photobox. This was inspired by the fact that a user has already used Entangle for such a system in the past. The plugin basically just hides the menu bar, toolbar and camera settings panels, adds a large “capture” button and then puts the app into fullscreen mode. Working on this helped me identify a few issues in the codebase which were making life harder than it needed to be – for example there was no easy way to get access to the GtkBuilder object associated with a window, so getting hold of individual widgets was kind of tedious. With the first cut of the plugin now written and working, it should serve as nice example code for users interested in figuring out how to write more plugins. At the top of the list for plugins I want to work on next is something to automate the shooting of an entire sequence of images. For example with astrophotography it is common to take sequences of many 100’s of images over several hours. You quickly become bored of pressing the shutter button every 30 seconds, so automation is very useful.
Windows porting
One of the memorable quotes from LGM was
“5% of the Windows market is larger than 95% of the Linux [desktop] market”
While I’m not personally interested in using Windows on the desktop, preferring GNOME 3 and open source software exclusively, I realize that not everyone shares this viewpoint. There are plenty of people who want to continue to use Windows for whatever reasons they have, but wish to be able to use cool open source applications like LibreOffice, GIMP, Digikam. The Nikon provided software for DSLR control is not cheap, so there’s clearly an opportunity for Entangle to be useful for Windows users. The key factor from my POV is minimising the overhead / costs of maintaining the port. I don’t want to have to use Windows on a day-to-day basis for this porting work, so getting it working using Mingw64 and hopefully WINE is a pre-requisite.
Entangle depends on a number of 3rd party libraries the most critical of which are of course GTK3 and libgphoto2. GTK3 is available for Minge64 in Fedora already, but libgphoto2 is not in such good shape. There is clear evidence that someone has done some amount of work porting libgphoto2 to Windows in the past, but it is unclear to me if it was ever complete, as today’s codebase certainly does not work. One evening’s hacking was enough to fix the blocking compile errors exposed when cross-compiling with Mingw64, but that left many, many 100’s of compile warnings. Even with the native Linux toolchain, libgphoto2 spews several 100 compiler warning messages, which really obscure the warnings relevant to Mingw64. So I’ve spent several more evenings cleaning up compiler warnings in libgphoto2 on Linux, resulting in a 17 patch series just submitted upstream. Now I can focus on figuring out the rest of the Mingw64 portability problems in the codebase. There’s still a way to go before Entangle will be available on Windows, but at least it looks like it will be a feasible effort overall.