On Feb 17, 2008 5:07 PM, Tor Lillqvist [EMAIL PROTECTED] wrote:
Perhaps for the rotation tool it doesn't mean much, but at least for
the perspective tool it would be nice if one could undo the
incremental changes one does to the control points. Probably this
wouldn't be hard to implement? I
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
On Feb 17, 2008 9:18 AM, Tor Lillqvist [EMAIL PROTECTED] wrote:
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
Will we be able to do undo *between* the strokes ?
* before Do it?
* after Do it ? In other words, will the undo stack be updated
after each stroke ?
After Do it, yes, definitely.
But before, that is a tough question. In my first patch (which is not
good), each stroke is undoable,
Hi,
On Sat, 2008-02-16 at 17:29 -0800, Bill Skaggs wrote:
I have doubts that the Warp tool should be a paint tool at all -- it
certainly doesn't use a brush.
If it doesn't use a brush, then it is not a GimpBrushTool. It can still,
and probably even should, be a GimpPaintTool.
Sven
Hi,
On Fri, 2008-02-15 at 20:43 +0200, Tor Lillqvist wrote:
what is the proper division of tasks between a GimpTool and a
GimpPaintCore?
A GimpPaintCore is an object used by paint tools. It does the actual
painting and it is also used when the painting is done by means of a PDB
call.
A
Hi,
On Fri, 2008-02-15 at 12:57 +0200, Tor Lillqvist wrote:
So, how to solve this? Should the bookeeping of deformation vectors be
done per-drawawble by the GimpWarpTool object (a subclass of
GimpPaintTool) and not GimpWarp object?
No, the tool class shouldn't do anything but providing the
On Feb 16, 2008 2:08 PM, Tor Lillqvist [EMAIL PROTECTED] wrote:
But isn't each stroke with a tool a separate GimpPaintCore object?
No, a GimpPaintCore is basically an object that creates brush-marks.
A paint tool creates its paint core when it comes into existence, and
uses the paint core as
Unfortunately now that I have had time to think a bit harder, I
understand that there is a fundamental difference in how my initial
effort to implement a warp tool works compared to how the IWarp filter
does.
Basically, when using the IWarp filter, and manipulating the preview
in its dialog,
On Fri, Feb 15, 2008 at 2:57 AM, Tor Lillqvist [EMAIL PROTECTED] wrote:
Unfortunately now that I have had time to think a bit harder, I
understand that there is a fundamental difference in how my
initial effort to implement a warp tool works compared to how
the IWarp filter does.
Do you
Do you really need to do it exactly the way the filter does it?
From your description, I don't really understand why your
current approach is less valid, or even why it will produce a
significantly different result.
It does produce a significantly different result. In my current code,
On Wed, 2008-02-13 at 02:06 +0200, Tor Lillqvist wrote:
[...]
Is it conceivable to have a Filter Brush that takes any filter,
ala krita?
Liam
--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net
Hi,
On Wed, 2008-02-13 at 02:06 +0200, Tor Lillqvist wrote:
Currently it allocates a big buffer for the deformation vectors, two
doubles for each pixel in the image. This should probably be changed
to either use tile-based storage, or use a scaled (when necessary)
deformation vector array
13 matches
Mail list logo