Krita 4.0 released, conversation with the team

Krita 4.0 released, conversation with the team

After 1.5 years in the making, Krita 4.0 is finally released with a ton of improvements mostly for digital painting, but also with a number of features useful for general image editing.

Here are some of the release highlights:

  • Vector graphics tools rebuilt with SVG and improved
  • Much simplified creation of word balloons for comic artists
  • New, easier to use text tool
  • Python scripting, a set of rather useful plugins, and a manager for them
  • Colorize mask tool for quick colorization of sketches
  • Background saving of project files

You’ll find detailed information on these and other news features in the release notes.

Now that Krita v4.0 is finally out, we had a little conversation with Boudewijn Rempt, Wolthera van Hövell tot Westerflier, and Scott Petrovic.

First of all, congratulations to getting v4.0 out of the door. This release is quite an achievement! What are you most proud of, in terms of team work or maybe your own personal involvement?

Boudewijn: I'm proud of all of it. We started coding on this release in 2016, with the export warnings feature, and maintained coding velocity all through 2017, doing 3.x releases along the way. There's just so much in this release... And then today, we released Krita with scripting and almost immediately someone published a script to publish images on Mastodon from Krita. That's amazing, isn't it?

You had to rewrite both internals and parts of UI for this release. What were the challenges UI-wise during this release cycle? Or maybe internal changes were more prominent?

Boudewijn: There are some parts of Krita where the big challenge was to let them be, for now. We know that resource management is a tough problem, and our current code is... Well, it was designed for the simple nineties, and extended and expanded beyond what it can bear. But to redo that for this release just isn't feasible. Leaving something alone that we know that is so problematical, well, that's hard! Same with the text tool in some ways. I know what I want to do there, but I couldn't, being tied up with non-coding chores.

Scott: In terms of the UI, it was surprisingly easy for the most part. I think our team is getting more in sync with our design and development process with what needs to be done.
The vector tools and the text tool UI designs mostly had positive feedback and only minor tweaks. I spent a long time studying workflows and UI patterns across a variety of free and proprietary programs before presenting the current solution.

The most difficult part of the text and vector project was to establish what the functional requirements were and scoping how much could get done. With all UI design projects I try to plan for a long term vision that people get excited about. I then modify the UI depending on how the developers are doing with time. We prioritize the features that will make the biggest impact when we get in a time crunch.

The most challenging part of the UI for Krita 4.0 was all the updates to the brush editor. None of the work was planned, but I felt it was the UI area in Krita that needed the most attention.

The brush editor UI has been a certain way for a number of years. You could tell there were features slowly added over the years without the overall design being thought about. It was difficult for people to see the brush settings differently and break the existing mold.

There were a number of existing problems with the 3.x brush editor in our bug tracker. I tried to anchor the design discussions on solving the current problems instead of being scared when a disagreement arose. Logic behind UI decisions has been the driving force for solving disputes and breaking free from old patterns..

Wolthera: Or in my case, not at all interfering with the settings discussion. For a long time user, discussions like these always tend toward 'Oh, but, is changing all that really necessary? Isn't there more problematic areas to tend to?', I recognised that in myself, so I just left it alone having full faith that Scott wouldn't come up with something unusable.

After Scott was done, all that I did to the editor was a little bit of polish and we had to work something out to get a 'create preset from scratch' function. It isn't used super often, as artists tend to modify existing presets. But when we create a new brush engine or the user removes all presets but one, the from scratch function is kind of necessary to even make presets.

What are the major changes in vector features you want going after next?

Boudewijn: SVG Filters, patterns, fixing UI stuff, fixing more ui stuff, fixing bugs. So please do report bugs!

Actually, we already have an implementation for SVG filters, but it has been disabled for ages. You can enable it by adding a line like


to your local ~/.config/kritarc and removing the filter tool entry

Not sure whether the filters save and load correctly, though.

Scott: I would like to see the vector tools and the text tools workflow merge a bit more than it currently does. Because of time constraints the user experience for the text tools had to diverge a bit than what we originally were planning. Right now some of the properties for text are in the vector area like border and fill, while the text editing properties are in the text tool. I am not sure what will get done though.

Do you follow development of SVG 2.0?

Boudewijn: We follow Tav :-) [Tavmjong Bah, developer of Inkscape and SVG working group member—LGW] I subscribe to his Patreon, and I follow his commits to Inkscape closely.

Gradient editor is currently in a docker. Is this temporary, with on-canvas editing planned for the future? Or will you keep it like this?

Wolthera: We're keeping it like this for now.

Scott: Right now all of our tools have tool options that can be used to customize how a tool works. Filling a vector object can have multiple ways to fill it: none, sold fill, gradient, etc. For each of these fill choices, there are additional options that can be specified. If the fill type is set to gradient, you can change the start and stop position on the canvas. The other properties must be set in the tool options. Keeping these options organized is very important in terms of usability, so I don’t see us specifically pulling those options out while keeping other options in a docker.

Why did you pick Python for scripting and not Lua (which is thread-safe)?

Boudewijn: Because pretty much the entire VFX world uses Python, and because I wrote a book about Python in 2000 :-). And... Well... There is no safety in threads.

How much of internals are covered by scripting for 4.0?

Wolthera: A very small part. We wrote a separate wrapper library to handle the more difficult to understand parts, and then turned those into Python bindings with SIP. Thing is, with each function we expose, we need to ensure that it doesn't crash somehow, or cause memory leaks, and just has good documentation. People shouldn't have to worry about those kind of things, as long as they carefully read the API docs.

Boudewijn: Let's first see what people do with what we have now, and where the problems are, and which bits of the API need changes.

Given that you had to cut down on text tool work because of all the troubles with taxes, I'm guessing there will be more text tool features after the v4.0 release?

Boudewijn: Sure. We'll probably even replace the layout engine completely at one point. That's why we made the editor communicate with the text object using SVG. But we had to have something after having had me waste most of 2017.

What's the current layout engine?

Wolthera: QTextLayout.

Doesn't Qt use the Harfbuzz OpenType layout engine anyway, deep down?

Wolthera: It does.

Boudewijn: Qt still has two versions of Harfbuzz embedded, even I've tried working on an existing patch to enable vertical text, but that broke all menus, and it's a big and complicated thing.

Wait, two versions of Harfbuzz? That's crazy! Why?

Boudewijn: Because it's a complicated thing to completely port away from Harfbuzz v1. That version has some functions to work with glyph tables that v2 doesn't have, I think.

So I first started working on removing the copy of Harfbuzz 1 from Qt, but there's no migration guide, and both versions of Harbuzz have very little real documentation...

Do you have variable fonts on the radar?

Wolthera: Our goals are, font support wise:

  1. Get text flow in all important directions working.
  2. Get word wrap and text on path to work/
  3. Get OpenType features like ligatures and suchlike work.

And maybe FreeType 2.8 will be widespread enough by that time, so we can add variable fonts later.

Just to make sure: "text flow in all important directions" as in top-to-bottom block progression, basically, vertical writing systems?

Wolthera: Yes.

Earlier you mentioned focusing even more on painting and dropping photography-related features such as the RAW loader. Is that still the plan?

Boudewijn: I still want to. I don't think anyone uses it at the moment.

After all the work you've done on v4.0 and all the last year troubles, do you feel like you should take a vacation, go south, and just sit there watching sunrises on a sea shore and do nothing for a week or two? :)

Boudewijn: I'll be going to sunny Sevilla! Well, for LGM, but it will almost be a vacation! And tomorrow I'm going to have a haircut and spend some time drawing. Or bugfixing. Not sure yet.

Having read about your problems with the tax service, your community pretty much embraced you in a warm fuzzy cloud of love and support :) Where are you financially today, and how many people work on Krita full-time or part-time?

Boudewijn: We got our financial buffer back, which is good. We also have done one project with Intel, for the multi-core optimizations and are doing another one; that is funding Jouni's part-time work. Dmitry is funded by donations, and I am funded by the Windows Store sales. I burned out having a full-time job in a volatile company in 2016, then had the tax trouble, so it's a good thing I don't have to hold down a day job in addition to the Krita work right now. We'll be discussing another fundraiser during the sprint in May.

What’s the best way to support you while not being a programmer?

Boudewijn: Triage bugs! We're getting so many bug reports that are just thinly veiled support requests, and those need to be weeded out before I see them. We get more than a thousand bug reports a year, and they all need a good and careful answer, but only about a third need coding.

Wolthera: Beyond that, helping other Krita users, making write-ups of your workflow/making tutorials is really useful too. Being a free graphics program we attract a lot of people who don't understand computers but they want to draw and Krita is a program that allows drawing. This leads to a lot of basic problems like people not understanding that different file formats store layers or not, or why one brush is slower than the other, or just not having any idea of a painting workflow, so people answering those questions are very very welcome.

Was it useful? There's more:

9 Responses. Comments closed for this entry.

  1. Boud created a helpful guide to get started in Krita bug triaging:

  2. Alexandre Prokoudine 23 March 2018 at 8:25 pm

    @Buovjaga, thanks! I added the link :)

  3. Krita is getting awesome every time new release comes. It really is fantastic, I just wish the dev team wouldn;t decide on dropping photo editing related features. The Raw editor can go, because majority use Darktable, Rawtherappee etc to process the RAW pictures, however as shocking as it may sound, Krita and it’s painting brush engines are really working well for photo retouching.  The way you can use brushes in Krita is phenomenal. In addition filter layers (a.k.a adjustment layers) are just so awesome to use for image editing. It would be cool if Krita had some extra functions, maybe as plug-ins (in order to not loose digital painting software identity), for photography related things. GMIC alone makes things pretty awesome for photogs, a few photo editing centric functions added in few places of Krita could make it pretty much a perfect photo retouching tool as it is awesome digital painting software. With a few extras for photogs combined with digital painting features of Krita it can become a unique and even more incredible tool. Krita evolved into something awesome.

  4. @Danas We aren’t really “dropping” features that deal with photo editing, but we decided we can’t make a good product if we also focus on photographer’s workflows as well. We added animation a little while back and it created a very large discussion/debate about Krita losing its direction and becoming a watered down general image editor that isn’t very good at any one thing. The more disciplines you try to make happy, the more the application is pulled apart because different people in different disciplines have different workflow needs.

    We ended up adding animation because there was just about no raster animation product in open source at the time. We were trying to fill a gap that was not taken into account and seemed to be in desperate need.

    On the other hand, there are quite a few open source applications that have a focus on photographers. We are really trying to avoid an “us” vs. “them” battle that some people online like to create (ie Gimp vs Krita).

    We know some people like using Krita for non-painting activities. The best way photographers are going to make Krita more photographer-friendly is if the community develops Python plugins that can expand Krita’s functionality for them.

    While the core Krita product will probably always have a focus on drawing/painting, the plugin community can expand Krita out in any direction they choose. All we can do is make the most solid product we can and give people the API to extend it beyond what Krita core is designed for.

  5. Absolutely FENOMENAL to see the libre graphics applications get more and more integrated through the common file formats such as SVG, ORA and OBJ formats! Amazing. Can’t wai to try it out myself.

  6. I like that comment “there is no safety in threads”. There are still some people keen to get rid of the Global Interpreter Lock in CPython, to make it more multithreading-friendly. That means doing away with reference-counting and relying on garbage collection like, say, Java does. But then you get stuck with the usual Java problem of having to allocate a fixed heap size, which you usually don’t have to in Python.

    And multithreading is really something to be avoided, unless your code is CPU-bound. Otherwise it just multiplies the opportunities for obscure, hard-to-fix bugs.

  7. Krita 4.0.1 is now in Debian Unstable. It appeared in my apt-get dist-upgrade today.

  8. Wow krita is so cool

  9. Krita is very good.