This is an interim report on the Gill project. The project is turning out to be fairly difficult. This wouldn't be a big problem if I were working on it myself full time, but in the context of free software, it is a problem. This document explains how the project came to be difficult, and why I think it's worth persisting.
Gill is a vector graphics editor. It differs from other vector graphics editors in one important respect: it uses SVG as its native format, and is structured in alignment with the various W3C and other standards that make up SVG.
These goals have turned out to be rather binding constraints on the code. Consequently, several other vector graphics editors in development are currently more functional than Gill:
- Sodipodi, a Gnome Canvas-based editor by Lauris Kaplinski.
- Sketch, a vector graphics editor written mostly in Python.
- GYVE, a Display Postscript based editor from Japan.
- KIllustrator, the KDE vector editor.
There are a number of older vector editors that aren't intended as direct competition to programs such as Adobe Illustrator, as well, including:
That's a lot of editors. Thus, I think that Gill requires a fairly strong justification for its existence.
The biggest stumbling block in Gill is also the biggest reason why it will be cool when it's done: the DOM. Gill stores the graphic in the DOM, and uses the event mechanism to keep the display up to date. Edits to the document are done by tweaking the DOM. Part of the reason for this design choice was to experiment with the architecture, as described in my DOMination writeups. The experience so far has been painful enough that I would not recomment the DOM approach for applications in general.
However, within the context of SVG, sticking with the DOM is going to pay off in the long term. Specifically, dynamic SVG documents have embedded ECMAScript code with a DOM interface. This allows all kind of animation and interactivity effects (uhm, can you say "blink tag of the '00s"?). It should be possible to plug in an ECMAScript implementation such as ngs-js or the Mozilla JavaScript implementation.
Yet, the DOM has been a significant source of problems. For one, the DOM2 draft does not really support the model/view/controller architecture. In addition, it's been difficult to implement DOM simply and efficiently.
The remainder of this document presents the issues facing Gill in more detail.
DOM woes
One of the first problems I ran into was that DOM2's proposed event mechanism has problems supporting Model/View/Controller with multiple Views. I brought this to the attention of the DOM working group on 22 Jun and then again on 2 Sep. The response was lukewarm at best. I then wrote to the SVG mailing list on 3 Dec, and finally a concrete proposal on 15 Dec. So far, there is no real response. Please follow the links for a discussion of the problem.
The lack of response has been a pretty strong de-motivator for working on DOM. We're probably going to go ahead and implement the 15 Dec proposal regardless of the response from the W3C. It will enable us to build a DOM2-compatible language binding, broken or no.
We ran into some other implementation problems on Gdome which were basically our own fault. First, we tried to implement the "multiple interfaces on a single object" (ie, in DOM2, Nodes also implement the EventTarget interface) with multiple inheritance. Let me warn you now, implementing multiple inheritance in C is just pain city (at least the way we did it). Gdome is single inheritance now, and it's much happier.
I've also struggled a bit with memory management. DOM is basically designed for garbage collected (or at least reference counted) languages. There is no standard C binding for DOM aside from gluing together the C language binding for CORBA with the CORBA specification of the DOM API. If you did that, though, you'd have horrible memory leaks. We added ref/unref methods to the C binding, but it took a little while to get it right.
Moving target
One of the basic frustrations with implementing SVG is watching the standard change as we try to implement it. As one example, I spent some time implementing all the path commands, including relative and absolute mode, only to find that the next draft changed things around. But this is simply one of the "costs of doing business" for implementing a standard which is not a standard yet.
More troubling is when we run into trouble spots in the spec, such as fonts. When we started, SVG had no way to do fonts in an interoperable manner, as I described in my font shame writeup. It now has "SVG fonts", but there are definite problems. First, the use of non-SVG fonts is not prohibited in the conformance section, so I'm not sure that it's all going to work. Second, the SVG font mechanism is a lot more powerful than usual, allowing arbitrary SVG elements in each glyph. I'm also not clear on whether DOM modifications to the font are allowed. If so, it's going to be pretty damned hard.
A big standard
There is a lot to implement in SVG, especially the other standards it depends on. To get it all, we have to do XML, XML namespaces, XPath, XLink, XPointer, CSS2, JPEG, PNG, DOM2, and ECMAScript. Since we are doing this in C, we're having to implement a lot of the infrastructure ourselves. Daniel Veillard's excellent libxml helps a lot to get the XML stuff right, but quite a bit remains.
Complex interdependencies
A challenge of Gill has been that it's not all being developed in one module, but rather across many modules. In many cases, there are infrastructure improvements to be made to existing, released code. For example, eventually Gill will require some significant enhancements to the Gnome Canvas (for example, to support rendering to an RGBA target). But the Gnome Canvas is part of gnome-libs and has its own release schedule. One possibility is to make the Canvas extensible enough that these things can be added on the app side, but currently those hooks are not in place. We'll work it out eventually, but for the time being it makes life a bit harder.
Editing
At the time of this writing, Gill doesn't do any serious editing. It can move stuff around and delete elements, but that's it.
Interestingly, when Larry Ewing implemented the delete function, he found it easier to delete the canvas item directly, rather then doing it through the DOM as the architecture calls for. Of course, the fact that the DOM implementation is so unfinished was probably the main reason for this, but it's a cautionary tale nonetheless.
The lack of a solid and complete event implementation in the DOM is still the main thing holding back editing, but I hope to get basic Bezier editing in soon. I've been working on some spline editing UI ideas in a separate app, canvas.c, which is not based on the DOM.
The main advance of this user interface is to use the spline-fitting logic from METAFONT to automatically fit a smooth spline to the points interactively entered. Thus, you don't have to drag around to get the Bezier control points. Initial experience with this interface seems very positive - it seems possible to get comparable results as the usual 6 degree of freedom Bezier editor, but with a lot less work. I'm also guessing that it's going to be easier for people to learn.
Conclusion
In spite of these growing pains, the vision for Gill remains clear. We will keep plugging away at the work, upgrading infrastructure as necessary, and make Gill a truly useful package for vector editing, as well as a complete and standards compliant implementation of SVG. These are important goals, but more importantly, it will be fun!
I personally haven't committed much into the Gill codebase in the past few months (I am still trying to finish my thesis), but the work of Gill has been going forward. The ChangeLog shows many entries by Larry Ewing on the core code, as well as Mathieu Lacage, who's recently become active on the project, and has been cleaning and reorganizing. Miguel de Icaza and Nat Friedman have been maintaining the Bonobo interface, allowing it to be embedded in other Gnome apps. Sometimes it seems that it takes a village to write a free software app, and fortunately Gnome is a pretty nice village.
