On 16/02/2008, Sven Neumann <[EMAIL PROTECTED]> wrote:
>  No, the tool class shouldn't do anything but providing the user interface.

I now realize that the non-GUI code for a warp tool does not need to
be very interesting or complicated. One could maybe even just use the
existing displace plug-in for the non-GUI code. The only problem, if
it is a problem, with the displace plug-in is a matter of precision,
as it uses just signed bytes for the X and Y displacement, and IWarp
uses doubles.

It's the GUI part that has to do all the "interesting" stuff,
collecting separate strokes and build up a deformation vector array,
i.e. displacement map.

I guess, in a way the warp tool should be like the transform
(rotate/perspective/shear) tools. While interacting with it a preview
is shown. Separate mouse drags are incremental, and just add to the
in-progress build-up of data for the warp. Only when the user is
satisfied and explicitly chooses some "Do it" action, does the actual
warping take place. (Or would it be possibly to do it implicitly when
the user switches tools?)

So a more or less complete redesign of my current patch is indeed
needed. (But that's what I was expecting anyway.)

On 17/02/2008, Bill Skaggs <[EMAIL PROTECTED]> wrote:
>  I have doubts that the Warp tool should be a paint tool at all -- it
>  certainly doesn't use a brush.

Yes. I thought long about this for a long time back and forth, and I
had to at least actually get something done that works in some way, if
only to get visual proof that it is the wrong approach...

>  Multiple strokes are always treated  incrementally, though.

That is a problem. But as I said above, a complete redesign is needed
anyway, and if the warp tool is implemented more in the style of the
transform tool, this shouldn't be a problem.

Gimp-developer mailing list

Reply via email to