> There are basically two possibilities: starting over again with a big
> rewrite or writing this kind of stuff as a plugin in Krita, in the
> shape of a special layer type, just like we implemented the vector
> layer type.

Aaah? As a plugin? Well... why not?

> storing the stroke data with their parameters in the undo/redo 
> system instead of the before/after pixels. Which is also 
> something that's related to the action
> recording feature Cyrille has started.

Say... speaking of recording, have the rest of you ever heard of
Opencanvas (no, it's not open source)? 

http://www.portalgraphics.net/en/

Opencanvas is actually quite popular in Japan and getting quite
popular in western markets too. It's basically powerful enough,
simple enough to use, and has a community system that makes it 
Very visible, all combined with an easy work uploading system and 
an event playback option for All works uploaded, for major visibility
and hype. It's windows-only, but for those of you who have the time,
check it out. The trial version lasts for one month, and you can
download events of any of the files at the "community" section 
(the "favorites" are on top, too, thanks to a voting system) to see 
how people draw with it.

I actually bought 4.0 a few years ago (drawn by the hype), and uh...
ended up never actually using it. Actually, I've only now noticed
that it also has a hands-on brush editor. :\ It's pretty interesting
how they went about it though: they've included "hardness" in the
option by adding a second outline. Also, they make the options easy
to access in the editor by making them reaaaal small.

Also check out their "watercolor" tool, one of its major selling
points. It basically blends the current brush with the color
underneath to a degree (but not in the same way the Krita color
mixer does; yellow + blue gives you darkened yellow or lightened
blue, not green).

> We want to release a 2.0 in April

April? Aww. :( Any plans for faster release cycles?

> maybe so but it can take days to do the graphs and charts 
> required to make the explanation in that way 

Maybe but it's still more efficient than attempting the sometimes
near-impossible task of explaining in other ways. ;)

If a major architecture rework is to be done, and it requires
multiple developers to implement the feature, then a detailed
explanation + graph is actually much more time efficient than
explaining to each individual and Hoping they actually 
understood. It's the difference between writing a manual and 
explaining to each person that comes along.

I know the difference between raster and vector, but I thought
we were talking about a node system that would make both notions 
meaningless.


      ____________________________________________________________________________________
Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.  http://overview.mail.yahoo.com/
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop