Trunk: new framework for curves

[Boudewijn Rempt]

On Friday 20 October 2006 16:30, Emanuele Tamponi wrote:

> 	1- The tools based on my framework could use their own "strategy" to
> handle and create the curve. I mean, while the code for the tools itself
> (events and the like) can be just inherited from a base KisCurveTool, the
> real methods that create the curve are defined by a class owned by the
> specific tool: this class (I call it "strategy" but it as little to do with
> the strategy pattern)

Better rename it then. Pattern names are like big waving flags telling 
people "don't look closer, this is what makes me tick."

> will decide what to do when a curve is started or 
> moved, when a new clicks occour etc. To make an example, take two different
> tools: bezier tool and circle tool.
> 		- Bezier tool needs to add 3 controls points for each new click and
> manages more than one "segment".
> 		- Circle tool just take the starting point and the end point, and doesn't
> manage more than one "segment" (I mean, once the starting point and end
> point are added, the curve is committed)
>
> 	I hope this is clear to all of you. Probably the strategy class can be
> removed and all the code for handling the curve can be put in the base
> KisCurveTool and then inherited and possibly modifed by all the derivate
> tools.

Sounds reasonable.

> 	2- All types of continous curves can be converted to bezier curves. So,
> once you draw a circle or a square, you can right-click and "convert" it to
> a bezier curve. The bezier tool is automatically activated and you can
> begin modify your curve with the power of bezier controls.

Does this mean you want to replace the rect, circle, star, triangle and line 
tool with specializations of the curve tool? That would be very nice.

> 	3- Each "curve" could reside in a KisCurveLayer that give you the
> possibility of storing the Curve data in memory after the curve is
> committed (in Krita 1.6, after the commit of the curve, you cannot edit it
> anymore). The layer can be moved, and a right use of the transform tool
> permits that the curve can be transformed or rotated (or is it better to
> implement my own rotating/transforming methods?).

That would suck a bit: we really want one transform tool to rule them all.

> If you want to edit the 
> curve after it's is committed, you can again rightclick on the layer and
> click on "restore the curve": the bezier tool is activated and you can
> change again your curve. Obviously this needs to update the "curve data"
> after each transformation, and it will have some problems when "merging"
> two curve layers (the curve data is merged too? And in what order?)

That won't be a problem in practice, it's the kind of thing that straightens 
itself out when coding.

> These are my ideas and I really would like to ear what do you think about
> them. I'd like to use Flake code too, if it's possible, so I wouldn't
> duplicate anything.

In that case, the best thing may be a specialization of the flake shape class 
(using the same control method) that uses Krita brushes to stroke. That could 
be a bit hard to do, but Adobe Illustrator manages something very close.

> *ALL* types of critics are welcome! :) And other ideas too. Put here what
> do you think a krita user would need when using paths. 

For me, simple things are the best. It's cool to be able to edit old paths, 
but it's also to be able to smear & smudge and filter the result of drawing a 
path.

> I think that the 
> restoring of a previously drawn curve is the main feature we need. And also
> curve transformation is needed. Conversion of curves is something a
> photoshop user could really miss... 

I wouldn't know about photoshop. Your curve implementation for 1.6 was the 
first curve tool I have been able to use :-)

> But probably there are other things we 
> need to take into account.


-- 
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/20061021/0a7b5162/attachment.pgp