Whither Krita?

[Boudewijn Rempt]

On Saturday 19 September 2009, Dmitry Kazakov wrote:
> I've just read the thread...
> 
> *for Cyrille:*
> About filter-based approach that Gimp uses...
> 
> I've thought about something like that for Krita recently. And i've got the
> following idea:
> 
> All the actions on the image (except of painting) could be based on adj.
> layers. E.g. if you want to change the size of the image (or switch to a
> different colorspace), you can just add a proper layer into the stack. If
> you do not want to have an additional layer, you can merge it down.

Fix the transformation mask, and you're almost there :-). 

> I'm thinking this idea over on leisure... And i think i'll be able to
> publish details one day =)
> 
> This idea has many advantages:
> 1) We can keep design of the Krita extremely simple:
>   - a small kernel for managing stack
>   - a paintop kernel
> 2) All the featutures, like tranformation, CS-switch, channel-blending can
> be easily made as filters (mind! no kis_transformation_layer! its simply
>  not needed)
> 3) A user will have a uniform interface(!) for all actions
> 4) At the moment, we have too much code duplication in Visitors that makes
> image/ design weird.

Whoa, hold your horses, cowboy. We are certainly not going to completely 
redesign krita's core again. That will take three years, at least, and during 
that time we cannot move forward. Incremental improvements, yes, but not a 
wholesale heart transplant. 

One of the biggests issues during kimageshop/krayon/krita's development is 
precisely this: a tendency to redesign krita's core time and again. We've just 
had one redesign and while I agree improvements are possible it is not so bad 
that we need a redesign.

We need a faster tile engine, possibly a better recomposition visitor, maybe 
some more layer types, maybe even a layer type that is just a node graph, feel 
free to implement that, but we should not change our entire node hierarchy 
again.

> *for Boud:*
> About Git.
> 
> What are we waiting for? Will Git really help our project? If it does, why
> not just set up any public hub for that? Like github.com? Our git
>  repository without history is just 149M.
> Commits from a public hub could be transmitted to svn daily (Thomas, ping!
> Is it possible?).

Git would really help our project because we could make our private feature 
branches public and share them and because we could go to a new workflow where 
the maintainer picks the finished features from everyone's tree and integrates 
them in the release tree. But, as Thomas says, the effort seems to be 
completely stalled. I feel guilty, of course, for not giving a hand, but then, 
I know I am a compulsive volunteer and I don't have any spare time either and 
I know I'm a horrible sysadmin.

> About stopping features creation process and starting fixing bug.
> 
> There are many design issues that simply can't be fixed easily. I'd say we
> should "stop features creation and start discussion of the design" and make
> our code easy to maintain.

Many, many -- don't exaggerate! 


> *for All:*
> Someone said that krita has many abilities: vector graphics, raster and so
> on...
> 
> I don't think it's good to have all-in-one application. We shouldn't break
>  a basic principles of our users - "unixway" and kiss. Most of our users
>  are unix-users, right?

No, not really. Most users are KDE users -- but that doesn't translate to unix 
users. And the unix way died the day Emacs was ported to Unix :P. But what 
kind of an application we should make and what features should go in, that 
isn't decided yet. Whether we should have task-oriented profiles that switch 
the user interface between modes, or perhaps separate applications all using 
krita/image and relevant plugins, or one big application with a corel painter 
like interface, let's not assume that we already have got a final decision on 
that.

> That's why i think it's better to have good communications between
> Krita<->Karbon instead of an ability to work with vectors inside krita.

Well, and others will disagree. Don't forget: in Krita 1.6 we had complete 
integration with Karbon. Adding a vector object would activate Karbon's user
interface inside Krita. But that didn't work for all kinds of reasons. So we
sat down and designed a new paradigm for KOffice 2.0, namely: every app is 
specialized for a certain document type, and where other types of content are 
needed in the main document, we add small-grained objects that provide that.

That's what we're building now, and it's too early to change this again. We 
cannot yet tell whether that will work out or not.


-- 
Boudewijn Rempt | http://www.valdyas.org