Hackfest2015 Topics

Please add topics you would like to discuss or work you would like to see done at the hackfest.

Other pages: Hackfest 2015, Hackfest2015 Attendees.

Agenda

1. Introductions: DONE
2. Create Agenda: DONE
3. Hacking:
   1. 2geom: sync IN PROGRESS
   2. Tackle GTK3 flickering bug. IN PROGRESS
   3. Selection - boost multiindex NOT STARTED
4. Bugs IN PROGRESS
5. Code Review DONE
6. Code Documentation NOT STARTED
7. Roadmap Review DONE
8. Accessibility DONE

Work pages

• Killing Livarot

Discussions

SVG 2 strategy (Tav)

• Overview/rundown of relevant new SVG2 features. DONE See SVG 2 Features in Inkscape
• How do we handle fallbacks? Use Visitor's Pattern Code is tightly bound to Inkscape, must be internal.
• When do we add things to the GUI? Earlier, the better; with SVG 1.1 export.

Program flow (Tav)

• Diagram how Inkscape behaves/should behave on:
  • Opening a file.
  • Changing a style item (e.g. 'fill').
  • Moving a node.
  • Deleting an item.
    • Comment: Deleting an item causes Inkscape to create a new SVG document with containing the deleted item to allow pasting.

Motivation

Add a few random print statements in Inkscape and you'll see that Inkscape visits certain functions more often than one would think it should. Having well defined diagrams will allow developers to clean up existing code and to better understand what needs to be done to add new features. I've noticed that we suffer from "cargo cult programming" where people add functions without fully understanding if they are truly needed.

• Ideas
  • Better, easily referenced API documentation
  • Code reviews
  • `linux perf` can be used to identify performance critical functions

Comments from Krzysztof

This is a pretty big problem right now. The flow looks like this:

Something is updated in the SP tree

1. updateRepr() is called
2. new XML is written
3. XML modification listeners fire
4. SP tree is re-read from the XML
5. A recursive call to update() is made
6. Each of those update calls updates the rendering tree in turn.

As a result, changing the document height triggers a full update of the rendering tree, even though almost nothing changes.

The current approach makes it impossible to introduce errors that cause the XML and the SP tree to go out of sync, at the cost of performance. We could discuss what to do about this.

Refactoring

Can we decide on a roadmap to work with new APIs and compilers? How do we minimize breakages for downstream users? Can we balance risk with reward? How does each migration benefit the developers, package maintainers and end users?

Some possible changes to discuss:

• Moving to C++11 (AV) Alex adding tests to code base.
  • code cleanup/maintainability
  • improved data structures/templating
• Adding a hard Cairo 1.14 dependency (AV)
  • Fix bitmap downscaling issue
• Gtk+ 3 migration (AV) GTK3 missing some functionality.
  • Get rid of lots of conditional code
  • Get rid of embedded GDK library fork
  • Some "cleaner" API available
  • How do we handle canvas flickering/rendering issues? Alex working on clean-up.
• C++ification (AV)
  • Migrate widgets/dialogs to Gtkmm
  • Get rid of popt
  • Get rid of GObject usage
• Removing 3rd party Library dependencies from version control (AV)
• Change how we're utilizing 3rd party libraries (Josh)
  • Stop using Poppler internals, use the proper API via poppler-glib (https://bugs.launchpad.net/inkscape/+bug/239544)
  • Use newer Pango-Cairo text/glyph APIs (https://bugs.launchpad.net/inkscape/+bug/420822)
• Unnecessary profileration of namespaces (Krzysztof)

  Things like Inkscape::UI::View::View are excessive. I cannot imagine a scenario where we would need more than 2 levels of namespaces. Everything UI-related should sit in Inkscape::UI, without separate namespaces for widgets and dialogs which only serve to increase typing.

• Directory structure. (Krzysztof)

  Let's make a directory for the SP tree, and namespace it as Inkscape::SVG (or maybe Inkscape::DOM).

• Identify clever geometry code which can be cleaned up and moved to 2Geom. (Krzysztof) Join LPE

Accessibility

Amelia Bellamy-Royds, an SVG WG member, will be giving a talk at LGM on making SVGs accessible. She is available Monday afternoon and/or Tuesday to talk to us about how we can make it easier in Inkscape to make accessible SVGs. Things we can do include:

• Automatically generating alt text when converting from Text to Path. Tav has pushed a fix -- the text will be saved as aria-label attribute.
• Making it easy to add common ARIA attributes (Didn't really discuss this)
• Adding language metadata (so that screen readers know what they're reading, but also for other benefits)

I've summed up some of the discussion in two wiki pages: Accessible Graphics and Language Support. See also

• Bug #170340, "metadata: need User Interface for SVG accessibility features"
• Bug #1249423 "Properly support the <switch> element and the "systemLanguage" attribute".

Both of these bug reports existed, but they've been updated with new comments and references.

Misc

Topics from Inkscape g+ Page

• Style editor
• CMYK
• GTK3
• Native OS X
• Animation
• PDF Import, text as path (semi-broken)
• Text flow
• Swatches GSoC Merge in Progress
• Geometric bucket tool (Paid development?)

Testing

• Discuss Jenkins/unittesting/rendertesting.
• Unit tests: Google Test/Boost. DONE: We decided to go with Google Tests based on it being better with templates, a bit less verbose, and its use in lib2geom unless there is a major outcry on inkscape-dev.

Website (DoctorMO)

• How do people feel about it's current functions
• How should we move it forwards?
• Plans for mailing list migrations.
• Getting developers set up with local copies for hacking.
• Modifying wiki style (p {width: 60em}).

Roadmap Planning (Bryce)

Prioritize feature and infrastructure development work for next several releases. DONE: See roadmap.

Fundraisers (Bryce)

Brainstorm future fundraising ideas.

Community Development (Bryce)

• Championing FOSS ideals generally
• Expanding userbase
• Building up a strong evangelist user community
• Recruiting newbie developers, encouraging involvement, and mentoring
• Re-connecting with old timers
• Promoting existing developers into leadership roles

Hacking

Invert coordinate system (Tav)

If there was ever a good moment to do the coordinate system flip, this is it. (should coordinates be configurable in relation to the canvas?)

Comment from Krzysztof

We need to decide whether we want to keep the 3D Box at all costs, or is the coordinate system inversion a more important goal than having 3D Box. Being unable to fix 3D Box was the main reason I didn't commit this change when I initially made it. FWIW, I think the 3D Box tool is nearly unusable and needs to be rewritten from scratch. It also pollutes the entire codebase with special handling for its perspective elements, indicating faulty design.

Harfbuzz: Better CSS support and User Fonts (WOFF)

There will be a Harfbuzz documenting session taking place at the same time as the Inkscape Hackfest. Maybe we can get some expertise on how to improve our font handling. CSS now has much more sophisticated ways of selecting alternative glyphs that Harfbuzz may support. Also, it would be nice to be able to use user fonts, in particular WOFF fonts, into Inkscape. At the moment we rely on Pango for all our font related stuff and Pango's support for new CSS stuff and for user fonts is negligible if completely non-existent.

We met with the Harfbuzz developers. In particular, we discussed user fonts and OpenType features with Behdad. Behdad has already push changes into Pango that will allow us eventually to support WOFF fonts. He is also working on adding the ability to access OpenType font features through Pango (various ligatures, swashes, etc.) and should have in done within the week.

Swatches

Merge GSoC swatches dialog.

Tomasz Boczkowski has started working on updating it. He'll probably have some C++'ification done during the hackfest so we can do a code review.

REVIEW DONE Mostly some minor white-space issues.

Make Systems

DONE: Alex is doing an independent comparison to see if the simplicity of WAF outways the popularity of CMAKE.

We will start with CMake: We have a partial build system already done with CMake. This will be a great improvement over autotools. We'll evaluate CMake vs. WAF again at a later date.

CMake (Bryce)

A while back someone made a valiant attempt to get Inkscape built with cmake, but if this ever worked it's bitrotted to where it doesn't work presently. Hack it back into working shape on Linux, Mac, and Windows. Write up evaluation.

WAF (Krzysztof)

I would rather use Waf. CMake has its own, sloppy scripting language; writing anything moderately complex in it is an exercise in frustration. By contrast, Waf scripts can leverage all the mighty power of Python.

Killer feature: since Waf stores a database of what was compiled, it support wildcards correctly. As in, when the set of files matched by a wildcard in the build script changes, it will automatically recompiles the correct files, without the need to modify build scripts. CMake cannot do this, because it just generates makefiles, and Make cannot support wildcards in this manner because it does not have any persistence beyond what is stored in the file system.

Other things we could easily do with Waf are:

• render test integration
• automatically updating the AUTHORS file and the authors tab in the About dialog from Bazaar logs
• creating a completely standalone executable (using e.g. GResource to store data files in the executable itself)

Hardware Acceleration Experimentation (Bryce)

Create experimental branch using Cairo-GLX as the rendering backend. Evaluate rendering performance. Brainstorm follow up work.