LGM: Two Krita talks

One of the most interesting scenes found at combination events that assemble open source developers and software users in a single room is when each camp presents a talk about the same code. Libre Graphics Meeting (LGM) frequently offers up these scenes, including, this year, a two-perspective take on the KDE painting application Krita.

The developers' perspective is by very nature different than the users' of course: for any growing software project, the project leaders have to care about the architecture of the codebase, the processes of reviewing and merging contributions, extending the functionality in a sensible (and manageable) way, and so forth. Those issues rarely conflict with users' needs, although in some cases there is tension between the project and users when users are clamoring to have a particular feature now, but the "right" way to implement it is costly. See support for 16-bit depth colors in GIMP, for example.

On the other hand, it is common enough for a project's developers to be more motivated about adding new features than about fixing "soft" issues like usability bugs. New features are fun to write; tweaking the interface may not be.

The users' perspective on its own often seems to focus more on the application's workflow than its feature set. Clearly, when there is a missing tool or function, that takes center stage — but the rest of the time, it is other issues that dominate the feedback: the ease of finding particular functions, switching between contexts or tasks, customizing or configuring the interface. This task-oriented point-of-view can become unhelpful, too. Taken to its extreme, any individual's usability feedback can represent only one way to use the application — and each user only uses a subset of the application's functionality (sometimes a very small subset).

Exactly how different the user and developer views are varies greatly depending on the application, of course. A compiler's users are not radically different animals than its developers. For creative software like Krita, however, the two groups' perspectives can be very different.

Krita 2.3

Krita developer LukᚠTvrdý spoke first, highlighting the process and the changes that led to the project's new release, Krita 2.3 — which has the distinction of being the first version officially blessed as being "end user ready."

Much of what went into declaring Krita 2.3 ready for end user artists is under the hood: speed and stability improvements. The painting engine is six times faster than the previous release, Tvrdý said, and other operations are noticeably faster (including a twelve-fold improvement in the speed of the "smudge" tool).

Krita's main tool metaphor is pluggable brush engines, which can be added separately and tweaked individually, rather than a set of discrete tools (e.g., "paintbrush," "airbrush," and "pencil" as commonly found in raster image editors). The basic brush engines emulate physical tools: different types of paintbrush, chalk, spray, etc — but more advanced brush engines actually incorporate code that draws dynamically for the user. Krita 2.3 introduces several of these advanced brushes, including a hatching brush that shades areas of the canvas by drawing hatch lines, and the sketch brush that shades and fills areas around each cursor stroke. One could imagine naive versions of either tool (such as creating hatch lines simply by pasting a hatch texture), but what makes Krita's implementations worth mention are that they actually work in non-trivial ways to simulate natural media.

Since 2010, the Krita team has worked with interaction designer Peter Sikking to focus its development on painting, drawing, and sketching as needed by real digital artists, and a number of changes to the user interface have been made in the 2.3 release as a result. The layout of the toolbars is different than that of many other raster image editors, they are designed for accessibility with a pen-based tablet. Every brush that the user selects can be modified through a drop-down menu exposed in the top toolbar; there is complete custom control available over how pressure, tilt, and speed (if they are reported by the pen hardware) affect the size, color, opacity, shape, and behavior of the brushes. The relationship between the pen hardware and brush behavior can be controlled with response curves (not just fixed values), so that variations on the "light" end of the pressure spectrum can produce more subtle changes than variations on the "hard" end.

The Krita 2.3 interface also makes the color selector widget a far more prominent piece of screen real estate than it is in GIMP or most other editors. GIMP, for example, maintains a small foreground/background palette; to change either color the user must click on the widget to open a modal dialog box. Krita's color selector is adaptable to a variety of shapes, layouts, and color models (think Red-Green-Blue, Hue-Saturation-Value, Hue-Saturation-Lightness, etc). Changing colors is a one-click operation, which is far better for pen tablet users, and the color selector automatically keeps a history of recent colors visible as selectable swatches down the right-hand side to boot.

Finally, Krita 2.3 sports a few functions requested directly by artists. One is "mirror" mode painting, which renders mirror-image brush strokes on the canvas in addition to the strokes actually drawn. Another is the ability to rotate the canvas itself, on screen, without transforming the underlying image. As Tvrdý explained, this allows the artist to move the canvas like a physical piece of paper to approach it from a better angle — while it is easy to hand-draw a straight horizontal line, he said, most people find it difficult to draw a completely straight diagonal or vertical line with a tablet. The rotation feature makes these actions trivial. Last but not least, Krita's interface is built with dockable widgets that the user can reposition at will. The new release allows users to save set of docker positions and tool options as reusable "workflows," so each user can maintain several set of UI tweaks built around particular tasks.

Tvrdý commented briefly on Krita development, noting particular that the application has found great success working with Google's Summer of Code program. Tvrdý himself was a GSOC participant three years ago, and observed that one of the best features of working with the program is that it allows the mentored student to see his or her finished code incorporated into Krita in only a few months' time. Partly that is due to GSOC's time constraints, but it also depends on the Krita team's ability to make projects workable and to keep the code architecture modular enough that GSOC-sized chunks are feasible.

Pen and ink

The list of features and UI changes in Krita 2.3 might have been a standard-issue update report had Tvrdý not been followed immediately on stage by an artist who uses Krita every day. Timothée Giet is a painter and comic book artist who produces his Wasted Mutants title in Krita. Giet did a live demonstration of how he creates an individual page in Krita, from blank canvas all the way up to full color, lettered product.

Perhaps the first thing a software developer might notice about Giet's workflow (hypothetically, that is; the Krita team is no stranger to him) is that he makes heavy use of only a small set of the application's features — perhaps two or three of the application's dozen or so brush engines. Which subset he uses is style-dependent. Comic books (even those that are drawn digitally) tend to emulate the look of hand-drawn artwork that includes a separate black ink layer, a separate color layer, separate text layers, and separate grid boxes. In the print world, these steps would historically be performed by separate artists; in the one-man digital comic world, they result in numerous stacked and grouped layers. Whereas a photo manipulation might require only three or four layers, Giet ended up with a dozen or more, all for a single panel.

It was also interesting to watch how Giet built up the layers of the drawing with different tools; starting with the aforementioned sketch tool — which he used with a very compact set of brush constraints, a choice that lent a distinctly different look to his results than most of the sketch brush demos showcase. He used mirror mode to quickly sketch out a pair of characters that he subsequently inked in using two different methods.

Giet also chose to undo and redo the same areas again and again, rapidly changing the brush settings and adjusting the colors as he did so, until he found exactly the right look. It is sometimes tempting to think of Undo as a function reserved for when one makes a mistake (as it frequently does in a word processor), but rapid, multi-step undo and redo can also be a core part of the creative process. If it was not as fast as it is in Krita 2.3 or if undos were limited to a small number of steps, this process likely would not have worked.

As Tvrdý implied when discussing the project's feedback mechanism with real-world artists, Giet used a number of pre-sets in the interface and tool settings. In addition, during the audience question-and-answer session, another artist in the crowd asked about the saved pre-sets (specifically, how many were available). As with Undo, it is easy to think of something like saved pre-sets as a "minor" function — after all, a new brush engine takes considerably more work to develop, and extends the core functionality of the application. But saved pre-sets garnered more attention from the users even than the highly-unusual sketch brush.

Another artist in the audience asked Giet how he managed the multiple pages needed to publish a comic book issue; he responded that he currently uses a separate file for every page. The Krita developers, however, said that multi-page documents were on tap for the next version of the application.

Giet is a single artist, so his way of working within Krita may have no bearing on the painter or artist sitting in the next seat — particularly with respect to the tools used. What Tvrdý said about the project's UI changes better fitting real-world artists seemed to hold true, though. From time to time, Giet changed brush settings and colors every few seconds, and the pen-friendly selection widgets were obviously an order-of-magnitude faster than an interface based on pop-up dialogs would have been. After the talk, Tvrdý mentioned that he found it painful from time to time during Giet's demo to see the artist struggle with one bit of the UI or another; that could be one of the most useful bits of feedback of the entire process.

Overall, the development teams that have made a habit of attending LGM over the years seem to have reaped tangible benefits. Unfortunately, graphics applications may be one of the few areas of computing that make live feedback sessions and demos easy to perform — it is hard to imagine the same sort of session for a spreadsheet, IDE, or accounting package, for example. But who knows; perhaps it could be easily done, provided both sides of the equation were interested in taking the stage.