TODO: was, Re: An even more flexible convolution painter
boud at valdyas.org
Fri May 27 22:01:42 CEST 2005
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050527/052daf08/attachment.pgp
More information about the kimageshop