whither krita -- summary

[sven.langkamp]

On Thu, Sep 24, 2009 at 9:57 AM, Boudewijn Rempt <boud at valdyas.org> wrote:

> Looks like the discussion has run its course, so I want to make a shortish
> summary, juxtaposing the things mentioned. There were a couple of
> interesting
> things noted! But that doesn't mean we've found our direction.
>
> There are quite a number of contradictions:
>
> flexible, comprehensive app  <---------> polish and usability
> platform for experimentation <---------> stable application for users
>

Can be solved by experimental and stable branches. Instead of makeing
experiments in trunk, you would have a seperate testing ground which allows
to merge new experiments earlier. Ideally we could keep the stable branch in
releaseable state most of the time.


> creating images              <---------> manipulating images

integrated in koffice        <---------> attractive to artists
> corel painter                <---------> photoshop
> competing with gimp          <---------> competing with mypaint
>

I think Krita is somewhere in the middle. There was an very interesting
video posted by the Durian project:
http://durian.blender.org/news/tutorial-painting-time-lapse-by-david-revoy/

It's not only amazing art, but also very interesting from workflow point of
view (for me as non-artist). I especially noticed how often he switches
between from MyPaint to Gimp and back. Each time the image needs to be save
and opened in the other app. I think switching between different
workspaces/modes would be much better. For example we could have different
workspaces for painting, image manipulation and vector drawings.

The dockers system we currently is quite flexible and allows lots of
customization, but it mixes too much different things in my option. The
dockers should adapt to the task I want to do at some point. For example I
have very often a situation where I was first editing some shape layer and
then switch to a pixel based layer. While editing the shape layer I use the
add shape, stroke properties and styles docker, but these are useless when
editing pixels. So I tend to close and reopen dockers quite often.


> go all node                  <---------> continue with the current core
>

I think sooner or later we end up with a node system. It's not "all node" vs
current corre, but the current core could be used a base to evolve into a
node-based system. As Cyrille said this should be in seperate branch.


> Use cases I've seen in the thread:
>
>  * photo manipulation
>  * HDR workflow (for film or for pictures?
>  * illustrations and comics
>  * sketching
>  * integration with movie workflow, blender
>  * web development (what is that, actually?)
>
> Can all these things work in one application?
>

Yes, I think so. Also the last point has other requirements the the rest in
terms of fidelity.

>
> Reasons to work on Krita:
>
>  * can do experimentation
>  * want to create an app I can use
>  * it's fun to work on
>  * prefer qt, c++ over gtk, c (I find this a bit disappointing, this can
> hardly become a compelling reason for people to use the application)
>
> Work flows
>
> And there are differences in the way we work personally that also influence
> the characteristics of Krita: Cyrille paints using small brushes, I tend to
> use big brushes on big, high-res canvas. That means a very different
> workflow.
> I love enkithan's comic book artist use-case, and I think we need more of
> them. (It also makes clear that we need to work on memory consumption and
> performance first thing! 1000 dpi A4...)<https://mail.kde.org/mailman/listinfo/kimageshop>


4K (http://durian.blender.org/news/4k_glimpse/) ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090924/81be0127/attachment-0001.htm