Change of maintainer
boud at valdyas.org
Tue Mar 9 09:40:12 CET 2004
On Tuesday 09 March 2004 02:52, Sven Langkamp wrote:
> I think we should put up some realistic goals which should be reached for
> alpha state.
We endeavor to give satisfaction... I've whipped up such a list, which is, of
course, open for discussion, and the individual items are open for adoption:
I still think a decent alpha is quite a long way away, but it can't
hurt to think about what we need to do before we're there -- and who
knows, maybe we're closer than I thought. I'm not sure how we can go
about releasing an alpha separately from KOffice, but no doubt we'll
be able to find a formula.
Anyway... This is the feature set I think we minimally need in order
to be able to call Krita an alpha.
- Session management (restore state of dockers, brushes,
- Brushes, patterns and gradients should always be presented
in the same order.
- Menu options to be consolidated and ordered.
- Dialogs ui-fied.
- Preferences dialog (needed to set max undo levels)
- Krita now considers creating the image upon startup an undoable
step; that needs to change, because if you start Krita and
close it immediately, you don't want to be asked whether
you want to save the empty image.
- Fix the scrollbars
- Investigate the issues with zooming; compare Krita zooming
strategies to KOffice zooming.
- Gradients (either Gimp gradients, which was planned, or
something better. Should use the ResourceMediator.)
- Remove the code duplication in KisResourceMediator with
something a little cleverer.
- subpixel positioning for the Brush tool
- a Pen tool that does what the Brush tool does now
- Clone/Stamp tool
- Shapes (Ellipses, Rectangles -- we already have a Line tool)
- Selection tools (freehand, circle, fuzzy)
- Smudge/convolve tool (perhaps subsume under a filter tool that
can use any filter definition to work like a tool, see Perico
for an example)
- Text tool
- Support more than one active tool.
- transform (code is present, but doesn't work, and I don't
know why. What I do know is that it's horribly bit-depths
and colour-strategy dependent because it's copied from
- smoothscale (to be copied from QImage).
- cut & paste from clipboard.
- Layers should render onto a generic RGBA buffer before being
composited for display.
- Timer-based redisplay (no explicit notify necessary anymore.
The timer based redisplay should go in KisImage. KisPainter
should pass the dirty rects to KisImage, KisImage should
start the redisplay for the normalized set of dirty rects
every timer event; when it takes to long, cancel the
redisplay -- this is also in some measure how the Gimp
- Fix the CMYK colour strategy (important, because that will
force us to never hardcode for RGBA).
- Extend painter with painting/filling with patterns and
- Extend the composite ops with support for opacity.
- Support for channels and masks
- Audit the core code for 8-bit and rgba assumptions and
flag those (or fix, if easy).
- Remove abort()s.
- A blur/sharpen plugin is pretty basic, and would help define
the plugin interface more accurately.
- A red-eye plugin would give us instant happy users.
- Remove all unused code so we have a clean slate to continue
I think we can stay with 8 bits for the alpha, but we should
strive for 8, 16 and 32 bits per channel for the 1.0 release.
This may well need some redesign.
An alpha can be buggy as hell, as far as I am concerned, but
the UI basics need to work, because without a working UI,
nobody will take the trouble of testing. And for a decent
test, the basic features need to be there, so we can see
how they interact, and so people can see what it's going
to be like.
KOffice is moving towards the OASIS file format. However, from
a cursory inspection of the OASIS documents, it doesn't define
a raster graphics file format. XCF can support everything
Krita can do right now. I'm not sure whether it can support
images with a channel depth > 8 bit, but it's no doubt
extensible. As soon as we have more advanced capabilities,
like images that support the wet & sticky model, we will have to
move beyond XCF. So I propose to retain, for the moment, our
own file format. It's not terribly urgent until we have something
that's nearly usable anyway.
Long term plans:
If we can get these features working relatively bug-free, on
images with 8, 16 and 32 bits channel depth, I think we have
enough for a 1.0 release as part of KOffice.
After that, I really want to start stretching the flexibility
of Krita's design. There are all kinds of cool things done,
like Salesin's research on watercolour or the Dab project, and
I think that there's an opportunity to make Krita into
something that's unique, instead of being to the Gimp what
Paintshop is to Photoshop.
It may look like a laundry list we'll never get washed, but
if you look at what's been done since October, I'm not so sure
we couldn't have an alpha in September.
On that tack: I wouldn't mind hosting a hack-weekend or
perhaps a hack-midweek for Krita developers at my place in
Deventer, the Netherlands, Europe, this summer. If people
don't mind sleeping on an inflatable mattress, I can easily
feed and house the entire current Krita team. I can probably
provide half a dozen computers that run KDE and are networked,
and a long table to put them on and work at. And history shows
that a hackathon now and then can really propel a project
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi
More information about the kimageshop