|
|
Subscribe / Log in / New account

Development

LGM: Two Krita talks

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

[LukᚠTvrdý]

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

[Timothée Giet]

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

Quotes of the week

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)

Some interesting GNOME Shell extensions

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)

LyX 2.0.0 released

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 1.4 released

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 organization for PostgreSQL assets

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)

Thoughts about QT 5 from Nokia

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

Development newsletters from the last week

Comments (none posted)

Introduction to programming in Erlang (developerWorks)

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)

Pinta turns 1.0 and brings simple image editing to Linux (Linux.com)

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>>


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds