Hi all,
We had a very good meeting this morning. Nine (9!) Inkscapers were present (partially thanks to the Inkscape development fund). Here is a list of those present:
Martin Owen/doctormo (barcode extension, Python, C++) Joakim Verona (artwork, Inkscape with emacs, d-bus, interest in embedded Inkscape) Krzysztof Kosiński (Clipboard, Cairo renderer, boolean path operations) Gémy Cédric/pygmee (extensions, Python, documentations) Sirko Kemter (LGM Host, Inkscape trainer) Elisa de Castro Guerra (documentation, translations) Ryan Lerch (Redhat user) the Adib (translation, Cairo, interest in PDF output) Myself
Here are some notes I took from the session merged with some notes from Elisa (thanks!). We covered a lot of stuff. Let me appoligize to those present if I get some details mixed up.
1. Community Development
The Inkscape community appears to be quite weak compared to other projects. We discussed a variety of reasons for this and possible solutions.
* The community appears to be quite fragmented due to multiple websites for code, bug-tracker, mailing lists, forums, etc. We should consolidate where possible. There could be better linkage between sites. The Inkscape website still needs to be expanded. For example, there is no page for translators (already fixed since our meeting, thanks Elisa and Martin!). Also, we need make sure that feature requests in the Inkscape forums get aggregated to the developers email list. Martin will try to find someone to volunteer to act as liaison.
* There appears to be a lack of direction. The Inkscape board is, by design, limited to controlling Inkscape's donations and trademark. Having some kind of steering committee might be beneficial.
* There is a lack of visible momentum in the project, exasperated by the long time between current releases. (We desperately NEED to get 0.91 out - as well as 0.48.5. People need to see progress.) More news articles are needed (with rapid translation).
* Paid developer: Synfig hired a developer who is now paid month-to-month by crowd-funding. This has actually stimulated additional developer contributions. People see progress being made and are more likely to make their own code contributions. There are weekly updates by the developer where people see the progress being made. (This is in contrast to the prevailing view inside the Inkscape community where paid development might threaten further contributions by non-paid developers.) Blender uses a subscription system. Many communities use a voting process to select the direction of paid development. We do need to be careful, as Scribus had a bad experience with a paid developer disappearing without delivering promised code.
http://libregraphicsworld.org/blog/entry/crowdfunding-for-sustainability-syn...
* Extensions is a place where people can easily make contributions. We need a web page with links to contributed extensions (or host them ourselves). (BTW, Blender had 8 part-time developers but still has a very active community of people contributing extensions.)
2. Paid developer
We discussed what we would want a developer to do if one were hired. Ideas were:
* Animation (high profile, improve sense of forward momentum).
* PDF Export (same as above).
* Plug-in structure (make it easier to contribute).
* Code clean-up and documentation (make it easier to contribute).
* Release (get timely releases out).
* Testing
3. Website Translations
Several problems were identified with translating the website. Translated news is being shown twice, once in the translated language and once in English. Martin and Adib will look into fixing this (some python coding). Also, translators are not notified of news updates. Martin will assemble a list of translators and set up a "cron" job to monitor changes to the website and then notify translators when changes are detected.
4. Technical discussions:
* 0.91 release: We need to get this out, even if there are a few remaining bugs. Adib will help with Windows builds. There is great demand for a GTK3 OSX build. It seems that the only hold-up is redoing the rulers as GTK3 dropped the ruler widget. Gimp has the same problem.
* Testing: We need better automated testing in both rendering and in unit-tests. cxxtests is awkward to use (and nobody seems to look at it, their are many tests failing now).
* Patch reviews: We need to be quicker in reviewing patches or we risk losing new devolopers. We might need to revisit our very easy access to code check-in rights. A person writing Python extensions might not be as proficient with C++.
* PDF Export: We discussed various strategies for improving our export to PDF, especially focusing on CMYK. Krzysztof has some ideas for achieving this. After our meeting, we had further discussions with people from Scribus on this topic. This topic is also coupled into possibly supporting other rendering methods (e.g. GEGL).
There are a couple possible solutions. One is to extend Cairo to handle color profiles. This might not be so hard as we could write out RGB but include a color profile to hand RGB to CMYK conversion. One problem is that Cairo doesn't support the color-depth we would like. The second is to write our own PDF exporter. While Scibus's PDF export code is tightly coupled to the rest of Scribus, it can serve as a good model of what we need to do.
The current "recommended" way of getting good PDF CMYK files is to pass Inkscape's SVG through Scribus. This is problematic as SVG support in Scribus is behind Inkscape's. Filters are not supported in Scribus. Adib will look in to possible filter support in Scribus.
* Export: Our export mechanisms needs to be unified, probably with a "visitor's" model.
* Filters: Needs to be reworked to follow the model of other objects. (There are hacks needed now to get the rendering done correctly.)
* Multipage SVG: We discussed ways to use groups (layers) to handle multipage SVGs. The layer dialog might be modified with some added Inkscape name-space attributes to have groups of layers of which selecting one will hide the others in the group. (This would make editing JessyInk presentations much easier!) Martin has volunteered to put a plan together.
* Remove need for "id" attributes. (Krzysztofv has an idea on this.)
* Excessive signaling. Why does dragging a gradient handle cause closed dialogs to call style handling code?
* Redhat/Gnome/Fedora had a series of requests already forwarded to the mailing list.
* BZR migration: BZR is no longer under development.