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 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,
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
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
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.
to post comments)