On 16/02/2008, Sven Neumann <sven@xxxxxxxx> 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 <weskaggs@xxxxxxxxx> 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. --tml _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
