TODO: was, Re: An even more flexible convolution painter

[Boudewijn Rempt]

On Friday 27 May 2005 14:50, Sven Langkamp wrote:

> By the way: Which major changes do you plan for the next release?

Well, there's the official TODO, of course... And the fixing of the bugs that 
will no doubt fill bugzilla. But there are a few things I intend to start on 
immediately after release (and after doing my exams):

1. Finish at least one painterly color model.
2. Make arbitray channel sizes possible in Krita
3. Redesign the toolbox/tools/paint ops etc. model.
4. Remove all ill-advised file format code from Krita.
5. Investigate koText for a possible candidate for a text layer type.
6. Adjustment layers.
7. Integrate wth Digikam.

To expand: I don't think cmyk very interesting. It's just that it is one of 
the easier things to implement that prove the color strategy design. I don't 
have a color printer, I never print my images -- I don't have the knowledge 
to work on that. Almost nobody needs cmyk, but without cmyk it'll be hard to 
get a favourable reception. Too late for that...

But painting I know, and painting is interesting. When working on the "wet" 
colormodel I found our current user interface doesn't allow enough control. 
For instance, a wet layer can handle only one paint op and no pattern fills, 
it needs a permanently running (in idle time) filter and a dedicated color 
widget. That's interesting to integrate in Krita -- applications like Corel 
Painter complain loudly if you try to paint a pixel on a wet layer or vice 
versa. That I want to avoid. 

A wet color channel is a short; that's twice as big as our current channels. 
So I'm going to need channel-size independence.

We already discussed in depth a design for an extensible toolbox. We need to 
implement that. It may be a good idea to look at Karbon; karbon already has a 
toolbox with sections for different types of tools (shape/transform/etc), 
with priorities that determine the ordering. There's no reason we shouldn't 
be able to wet-paint a polygon filled with strokes.

I tried to create something flexible for file format support, but it turns out 
we can (ab)use the KOffice filter system for that. We just need to extract 
our imp/exp code from Krita and add new filters for new file formats like 
exr.

Our text tool is cute, but not good enough. koText is a cool thing, it can 
already render formatted text to a rectangle with zoom and everything. I 
propose we re-use that code in Krita.

Adjustment layers are another very cool thing. A combination of a selection 
mask and a filter effect -- it should be easy enough to implement, although 
interactive speed at rendering may be hard to do.

And digikam is cool -- whether we add a portfolio plugin to digikam that 
assembles a set of images into a folder for Krita to work with or make a 
plugin that loads all Digikam plugins for use in Krita, either way we need to 
leverage the great achievements of Gilles and Renju.

And, of course, there are user interface things: locking layers and make that 
work, adding a channels docker, a history docker, a bird's eyeview docker -- 
make the docker tabs draggable, even -- and more.

But for me, as maintainer of Krita, the first thing is going to be integrating 
either "wet & sticky" or "wet dreams" into Krita. That'll expose a lot of 
holes in our design and will make Krita robust enough for anything.

On a final note: 1.4 has branched, the work is nearly done. I'm not going to 
be able to fix shearing with selections -- tried today, failed -- and having 
locked/invisible protect against changes is not going to happen either -- 
but, still, we have accomplished, everyone of us, an incredible feat. After 
six bloody years, four maintainers, six core designs (if not more) and only 
the Lord knows how many boasts and curses, we've finally passed the first 
milestone: actually shipping.

Thanks, guys!

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050527/052daf08/attachment.pgp