A hearty slap on the back:

[Boudewijn Rempt]

On Thursday 02 November 2006 06:20, Torsten Rahn wrote:

> I actually had the heart to read through all the feedback ;-) 

Me too. It wasn't too bad. What never ceases to amuse me is that after a 
decade of bitching about CMYK not being in the Gimp, every time Krita is in 
the news people are bitching about CMYK being in Krita. Oh fickle and 
inconstant humanity what doest thou want!

> I think Krita is now at the edge where it becomes a significant key player
> in the linux graphics department.

I do hope that in a year or so I don't have shudder when Inge writes an 
announcent or Nathan a review. Right now, every time, I think "Not so fast! 
We're good, but not _that_ good."

> However that needs to be taken very carefully as people who try something
> once will never return if it continues to be bad for a while and you'll
> have a hard fight once some prejudice has gained common sense (I think
> KOffice as a whole is still struggling from people who have tried it once
> early in 2000-2002 and have been so disappointed that KOffice is still
> suffering from those opinions).

I've seen very little of that in the past year: people are getting excited 
about KOffice again. I just wish Thomas would get his power adapter so he can 
continue working on KWord :-)

> The problem with much of the Krita feedback is that it's hard to say which
> users refer to 1.5 (which indeed was rather slow and clunky compared to
> 1.6) and which users actually did install 1.6.

Some of those comments gave the impression that they were still using 1.4 
even.

> I still believe that even for 1.6 the most important points that need to be
> addressed for backports and point releases are:
>
> - speed - especially wrt larger files: Large files indeed load slowly.
> However that's a showstopper for printing which in turn is meant to be
> addressed by the CMYK color space support. So there's a conflict here: On
> one hand Krita should be the ideal tool for printing due to its color space
> support. On the other hand it still has some short comings in the large
> file department which needs to be addressed given that high dpi pictures
> will always get larger than your favourite wallpaper.

Yes, this is a problem. One real problem is that the KOffice filter 
architecture assumes that you'll read the complete file you're importing into 
memory. I have spent much time thinking about this and haven't gotten nearer 
a solution. What we'd want to do is be able to use any file format as a 
read-only datamanager, but that would mean:

* making the datamanager methods virtual or adding another layer of 
indirection
* making it possible for an image to use two different datamanagers at the 
same time (file based datamanager and tile based datamanager (for changes and 
undo)
* more or less taking the import filters out of the koffice filter 
architecture

We need something similar for native files. I very much doubt that it will be 
possible to fix this in 1.6. Ideally, we wouldn't touch Krita's core anymore 
in 1.6 except for bug fixes, and only add new plugins. The new plugins would 
be ported before 2.0 would be released, and the bugfixes would be 
forwardported on the go.

In any case, startup of 1.6 has somehow gotten much slower than previously. 

> - further beautification: Like further improving the icons, which are a lot
> better than 1.5 already. Or like the suggestion for the color select
> circle.

I think the current toolbox icons are very good: I don't think we need to 
change those. The layout of dockers and dialogs could be improved, of course. 
The colorwheel should be easy. I actually don't know why we draw it: we could 
use a nice anti-aliased pixmap instead, giving us a smooth border in one go.

> - some further essential filters like colorize and dodge need to be added.
> ( I might actually be interested in working on some filter if I find some
> time beyond my pet project "Marble").

1.6 is the version to code new filters, tools, paintops and so on against as 
plugins. I will port all new plugins to 2.0 before we release 2.0 if the 
plugin author allows inclusion in our svn tree. So: code away!

-- 
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: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20061102/441df291/attachment.pgp