Hackfest2015 Report

Hackfest Report

Short Version

Inkscape developers met for a three-day hackfest in Toronto before the LGM meeting. We were able to get through a number of deep technical issues as well as spend time working on key pieces of code. At this hackfest we:

• Constructed a road map for Inkscape development for the next few years focusing on frequent high quality releases.
• Planned our move to use the best development tools, programming language features, and software libraries available to produce more reliable software and faster bug fixes, as well as improve support for OS X.
• Committed to making Inkscape and the graphics it generates highly accessible including superior support for screen readers and multi-language files.

Overall it was a very successful (and exhausting) meeting.

We want to thank all the sponsors who made this hackfest possible!

Long Version

Inkscape developers met for a three-day hackfest in Toronto before the LGM meeting. We were able to get through a number of deep technical issues that we needed to solve to move the project forward. We tackled build systems, testing frameworks, moving to C++11, our website, community development, and accessibility issues among other things.

We also hammered out key bits of code. Alex got started on fixing the way we render tiles to the screen, a necessary step to moving to GTK+ 3 and better OS X support. Krzysztof worked on merging his branch of lib2geom with its new path intersection code. I fixed an accessibility issue, saving text into an accessible string when converting text to a path. Jabiertxo began work on properly supporting the <switch> element and the "systemLanguage" attribute. This will allow "internationalization" of SVGs as well as allow screen readers to know the language of the text. We all reviewed Tomasz's C++ifying patch that is a key step to getting his new patterns widget into the Fill and Stroke dialog so users can preview patches and hatches before applying them.

We talked with Behdad Esfahbod of Pango and Harfbuzz fame (text rendering and shaping engines) about being able to use OpenType features through Pango and how to use "user fonts" which will eventually allow us to support WOFF fonts. We had discussions with the Belgium Open Source Publishing Group, "power users" of Inkscape (we also got interviewed by them for one of their publications).

Overall it was a very successful (and exhausting) meeting.

We want to thank all the sponsors who made this hackfest possible!

Here is a more detailed summary of what we discussed and decided:

1. Road map.

   We spent quite a bit of time updating the road map. We want to move towards more frequent releases where we focus on a particular area for each release.

2. Build system.

   Our current build system is based on autotools on Linux and Mac OSX, and on btool (a custom script) on Windows. We wish to have just one build system on all platforms. Autotools is quite complex and the number of people who can fix autotool problems is small.

   We had two competing replacement options: CMake and WAF. CMake is more common while WAF is simpler. We have decided to first move to CMake for which we already had partial support as adding support for WAF right away would mean supporting three build systems. After we have gained more experience with CMake and dropping autotools, we will reevaluate a move to WAF. The general feeling was that even if the move to CMake was temporary, we have a lot to gain by moving now. CMake offers us "ninja" builds which are faster and more easily parallizable than autotools. We will continue to support autotools for one release cycle as insurance against unexpected problems with CMake.

   With progress during and after the hackfest, we can now build with CMake on all platforms.

3. C++11

   C++11 offers many enticing improvements over C++98 and more than one Inkscape developer is chomping at the bit to be able to use C++11 features. The main holdup is that those stuck on OSX 10.6 or earlier (due to older hardware) do not have access to compilers that support all of C++11.

   We have decided to add to the Inkscape code base test code to evaluate what C++11 features are safe for us to use in light of the equipment that our current developers are using. We hope to allow some C++11 features in the near future.

4. GTK+ 3

   We want to move to GTK+ 3 as soon as possible. GTK+ 3 will give our OSX users a much better experience and opens the possibility of a tablet version of Inkscape. There are two things that are holding us up:

   • There is a "flickering" bug where the screen is not updated properly. This is due to our updating the rendering outside the main event loop. Alex started work on cleaning up the code during a hacking session.
   • Our UI was designed for GTK+ 2 widgets and needs to be refactored for GTK+ 3. For example, GTK+ 3 buttons tend to be bigger (better for use with fingers on tablets) and thus a lot of dialogs end up being too wide.
5. Internal libraries.

   We rely on quite a few internal libraries. Some are slightly modified copies of external libraries (e.g. libcroco) while others are tightly bound to Inkscape's development (lib2geom). In order to reduce the code maintenance burden, we wish to reduce our dependency on internal libraries. This means getting our modifications upstream, if possible, or breaking out the libraries.

6. Code organization

   Our code organization could use some help. One problem is the directory structure. Different parts of the GUI are found in different directory trees. The main directory contains a mish-mash of file types. One suggestion is to move all the "SP" files into their own directory. These are the files that roughly correspond to SVG elements. This would be one step in a long process of separating the rendering code, the GUI code, and the XML tree/CSS handling code into independent libraries.

   Another problem is the overuse of names spaces. We are getting some very long name-space strings: Inkscape::UI::View::View or Inkscape::UI::Widget::ColorEntry for example. We should decide on a set of shorter namespaces to use.

7. Testing

   We discussed testing a bit, probably not as much as we should have. We have automatic testing in place but its usability could be improved. (Getting an email everyday saying that things are broken isn't as useful as getting an occasional email saying that something new is broken.)

   We also decided to move away from the existing cxxtest framework to the Google unit-testing framework, choosing that over the Boost framework. Both the Google and Boost frameworks are more widely known.

8. SVG 2

   SVG 2 offers Inkscape users a lot of exciting new things: flowed text, mesh gradients, etc. Rendering support for some of the new things is already included in Inkscape. When do we expose these via the GUI? How do we handle graceful SVG 1.1 fallback?

   The general feeling was that Inkscape should be an SVG 2 editor and that we should expose new SVG 2 features in the GUI as soon as possible. Export to SVG 1.1 will be provided as an option (where practical). This export will be done via the "Visitor's Model" which allows all the SVG 2 -> SVG 1.1 code to be placed in one file. (Once this model is implemented, it can also be used for other export options, greatly simplifying Inkscape's export code.)

9. Accessibility

   We had Amelia Bellamy-Royds join us for a discussion of what Inkscape can do to make it easier to created accessible SVGs. She's a member of not only the SVG Working Group but also the SVG Accessibility Task Force. We tackled some low-hanging fruit as mentioned in the introduction.

10. Text improvements

    Our discussion with Behdad was quite fruitful. He gave us an idea on how to implement "user fonts" (fonts not installed on a user's system). He's recently patched Pango to make using them easier. We also discussed supporting OpenType features in Pango. This would allow us to do things like turn on/off discretionary and historical ligatures, use stylistic alternate glyphs, use diagonal fractions (automatically replace 1/2 by ½), etc. He's promised to patch Pango soon to allow access to these features. I've already added code to Inkscape trunk to read/write/modify some of the CSS style properties needed for these features.

11. Miscellaneous

    We covered a lot of issues that due to lack of time didn't get fully discussed: community development, future hackfests, fund-raising, a style editor, CMYK support, etc. Hopefully, now that we have some major infrastructure issues out of our way we can at a future hackfest give these the attention they deserve.