releasing inplications

[Michael Thaler]

Hi,

> Those are not what I see as the big advantage of a release: having a
> release transforms an application from being a playground to something
> real. We need that, or, more accurately, _I_ need that. Krita has to stop
> being a promise and grow up. The only way is through exposure to the big
> bad world. We'll get a lot flak for sure, because after all these years we
> still don't have a 16-bit/channel, cmm-enabled (okay, we've got that, but
> only rudimentary) Gimp killer with a side-order of real media painting. But
> if we don't do a release, we won't get there anyway.

I would also really like to see Krita released. I showed Krita at our LUG info 
event and some people seemed really interested. But unfortunately the only 
thing I could tell them was, that there are currently no packages for any 
distribution and that the only way to install it is from CVS.

But I cannot even recommend Krita to users experienced enough to install it 
from CVS. When I tried to make some paintings for my talk last weak, I 
realized how many things are currently broken. You cannot even save pictures 
in jpg or png.

I know that the changes made to the tile-manager were necessary and that these 
changes will improve Krita in the long run, but it is still a pitty how much 
things in Krita are currently broken, compared to the state Krita was in some 
months ago.

Releasing Krita with KOffice 1.4 would at least force us to fix all the bugs 
introduced with the new tilemanager. I think this really would be a good 
thing. I would rather like to see a relativlely bug-free and feature complete 
version of Krita with only RGBA8 support then wait another couple of years 
everything is implented.

I still think Krita should ultimatively support different color-models and 
channel-depths, but if this cannot be done until KOffice 1.4 is released, I 
think we should concentrate on the things that can be done.

> wouldn't mind that, but I'm a natural born glutton. But once there's a
> release out, people can work on plugins. Almost everything can be a plugin:

One thing Krita is really missing is an easy way to write plugins. We need 
functions like getRGBdata, setRGBdata, getCMYKdata, setCMYKdata and so on. 
Maybe it would also be nice to be able to access tiles directly to speed up 
prlugins. In the case the tiles store the data in RGB this would not be any 
problem. In case the data is stored in another colormodel, there should be 
functions to convert to and from RGB. 

I think most fitlers cannot really be written in a color-independent way or 
even if one could in prinicple, it is propbably much harder then just write 
an RGB one. This is especially true for porting filters from other 
applications like gimp to Krita, e.g. the GIMP fitlers asume RGBA8.

I know that in prinicple it would be nice to write everything color-model 
independent, but that would certainly hold off people from developing plugins 
for Krita because it is just too hard. I prefer having filters that are a 
little slower with CMYK or other color-models because the data has to be 
converted to RGBA firt then having none at all.

If I find some time, I will try to implement the polyline tool and the polygon 
tool. That should not be to hard.

Greetings,
Michael