Krita features (CC from KOffice list)
Boudewijn Rempt
boud at calcifer.valdyas.org
Wed Jan 14 14:20:30 CET 2004
On Wed, 14 Jan 2004, James Richard Tyrer wrote:
> And, if this was acceptable, we really need to focus on the application for KOffice first.
Even if we wouldn't agree to this plan, then it's still true that Krita first
needs to become at least as powerful as, say, KPaint... The following features
are still missing from Krita CVS:
Tools
- freehand painting ('soft' pen, 'hard' pen, airbrush)
- shape painting (lines, rectangles, ellipses
- selection tools (rectangle works, but freehand, circle, fuzzy, magic
wand and by colour are missing)
- eraser
- convolve
- fill
Gradients
- loading of Gimp gradients
- filling with gradients
- painting with gradients
Patterns
- loading of Gimp patterns works now, but:
- filling with patterns
Images and layers
- scaling of images
- colour channel separation
- create brush or pattern from image
User interface
- All tool option dialogs
- Preference dialog
- Gradient dialog
Core
- KisPainter class (a QPainter analogue, more or less) doesn't
support more than a rectangular fill and a simple bitBlt from
one layer to another. Should be expanded and extended.
Knowns bugs
- scrollbars don't follow image size/zoom size
- on startup, there is no default selected tool, brush and colour
There is more, but I guess you get the picture: a few years ago Krita was a
buggy, slow and crash-prone painting app that had working tools, now Krita is
quite robust, has a firm core, but everything else needs to be redone.
And then there's the agenda behind Krita's current development
(http://koffice.kde.org/krita & http://koffice.kde.org/krita/faq.php), which should
be kept in mind: quick & dirty hacks to have Krita working before KOffice 1.4
would make life harder later on, although a working app brings in developers.
Anyone interested in hacking could do worse than read:
http://koffice.kde.org/developer/krita/index.php.
The particular problem I am interested in solving right now is the freehand brush
tool, and then in particular the problem of an accurate brush stroke where one
doesn't have a mouse move event for every pixel the mouse covers. The old Krita
code combined with the new painting code is too slow (check the cvs version and
remove the
paint(pos, 128,0,0);
return;
lines from the beginning of KisToolBrush::mouseMoveEvent), and besides, I need
sub-pixel positioning to make the line nice and accurate. Both computing the
mask for the sub-pixel positions from the brush mark, as the in-betweening between
mouse position while still not making a curve consist of two or three straight
lines are problems that are hard to solve, for me.
When that's done, Krita at least can paint again...
(Cc'd to the kimageshop list)
--
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi
More information about the kimageshop
mailing list