May 11, 2011
This article was contributed by Nathan Willis
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.
Comments (4 posted)
Brief items
I certainly agree that perl6 is at least as much a different
language from perl5 as Java is a different language from C. I am
appalled at how messed up things have become. Even people who
should know better, people whom I explain this all to again and
again and again and again, will ever a few weeks' time lapse again
into the Successionist Heresy.
They once again start thinking of perl6 succeeding perl5 **NOT** in
the way that Java has succeeded C, but rather in the way that
Windows 98 succeeded Windows 95 or the Intel 586 processor
succeeded the 386. It is intensely aggravating to watch, yet who
can blame them? Every technical product they're ever used that
comes with an ever-increasing numeric suffix is one that is meant
to be "the next" version, one that will soon supplant that old
dinosaur.
This is a miserable situation that we're now quagmired in. It is
harmful to perl, because it is superlatively misleading.
--
Tom Christiansen
Sometimes related to the development of frogr, and sometimes not, I'd
like to thank here to some people who helped me in a way or another:
- * My girlfriend, who proved to have infinite patience all the time
+ * My wife, who proved to have infinite patience all the time
* My son, who was born right at the same time I started this project,
so they're some kind of "brothers" or the like.
--
Mario
Sanchez Prada - congratulations are due
Open source is different from a community-driven project. We're
light on community, but everything we do ends up in an open source
repository. We make the code open source when the first device is
ready. We're building a platform, we're not building an app. When
you're building a platform, you evolve and improve APIs, and
sometimes APIs are deprecated.
When you're dealing with new APIs community processes typically
don't work - it's really hard to tell when you're done, and it's
hard to tell when it's a release and when it's beta. And developers
need an expectation that the APIs they're using are done. If
someone were to look at an early release, they could start using
APIs that aren't ready and their software might not work with
devices.
-- Android's
Andy Rubin
Comments (4 posted)
Ron Yorston has posted
a set of GNOME
Shell extensions "
for grumpy old stick-in-the-muds."
Through some JavaScript magic, these tweaks add application launchers to
the panel, restore static workspaces, and more. People who are unhappy
with the GNOME 3 interface changes might want to give this add-on a
try.
Comments (32 posted)
Version 2.0.0 of the LyX document processing system is out. "
With this release, LyX celebrates 15 years of existence, and we start
a new family of 2.x releases to acknowledge LyX's passing from a child
to an adult. We hope you will celebrate this anniversary with us."
There are many new features in this release; see
the "what is new" page and
LWN's LyX 2.0 review for more information.
Full Story (comments: 5)
Passlib is "
a comprehensive password hashing library for python,
supporting over 20 different hash schemes and an extensive
framework for managing existing hashes." The 1.4 release is out; it
adds better LDAP support, PBKDF2 hash support, and more; see
the release
notes for details.
Full Story (comments: none)
A Canadian non-profit company is being set up to take ownership of the
PostgreSQL domain names, keys, trademarks, and such which have, to date,
been held by Marc Fournier. "
For years, we have had the issue that
if anything happened to Marc, getting control of these assets could be
difficult and cause us weeks of wasted time, and perhaps even result in
www.postgresql.org being offline for days or weeks. Even to date, we've
had issues where problems have happened while Marc was away and been unable
to resolve them quickly." The organization will be run by a board
consisting of Josh Berkus, Marc Fournier, Dave Page, and Chris Browne.
Full Story (comments: none)
Nokia's QT Labs weblog is carrying
a lengthy
posting looking forward to the QT5 development cycle. "
Another
major change with Qt 5 will be in the development model. Qt 4 was mainly
developed in-house in Trolltech and Nokia and the results were published to
the developer community. Qt 5 we plan to develop in the open, as an open
source project from the very start. There will not be any differences
between developers working on Qt from inside Nokia or contributors from the
outside."
Comments (18 posted)
Newsletters and articles
Comments (none posted)
There is
an
introduction to the Erlang programming language (the first part in a
series) on the developerWorks site. "
Erlang provides a number of
standard features not found in or difficult to manage in other
languages. Much of this functionality exists in Erlang because of it's
telecom roots. For example, Erlang includes a very simple concurrency
model, allowing individual blocks of code to be executed multiple times on
the same host with relative ease. In addition to this concurrency Erlang
uses an error model that allows failures within these processes to be
identified and handled, even by a new process, which makes building highly
fault tolerant applications very easy. Finally, Erlang includes built-in
distributed processing, allowing components to be run on one machine while
being requested from another."
Comments (7 posted)
Linux.com has
a
review of the Pinta image editor. "
What you get with Pinta is
indeed a subset of what you will find in GIMP. Drawing tools, just not as
many of them. Filters and effects, but a smaller collection. Layers and
image adjustments, but not every feature. For a lot of people, of course,
that is perfectly fine. The only question is how to determine which group
you fit into."
Comments (none posted)
Page editor: Jonathan Corbet
Next page: Announcements>>