Manish Singh <[EMAIL PROTECTED]> writes:

> On Fri, Mar 26, 2004 at 12:06:33PM +0100, Michael Natterer wrote:
>> Manish Singh <[EMAIL PROTECTED]> writes:
>> > On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote:
>> >> On Sun, 21 Mar 2004, Manish Singh wrote:
>> >> > On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote:
>> >> > > What requirements would the new PDB have?
>> >> >
>> >> > There's a number of issues to be addressed, like GEGL node support,
>> >> > efficiency, UI generation, distributed processing, and macro recording
>> >> > support.
>> >> 
>> >> Macro recording is already trivial with libpdb: you just connect to the
>> >> appropriate signal of the Pdb object.
>> >
>> > Have you given any thought on how to macroize interactive paint
>> > functions?
>> By simply passing an array of GimpCoords to the yet-to-be-generated
>> core PDB wrappers, just as all core functions will have to be invoked
>> via these wrappers to make marco recording possible.
> Well, something has to generate those coords, and something has to update
> the UI before painting is finished.
> I was asking more in terms of an API should look like. Interactive
> paint is more involved than say, a bucket fill, which is easily translated
> into to "call PDB bucket fill function on button release".

IMHO this is not a big issue, since even today PDB painting uses almost
the same functions as interactive painting does. The only difference
is that PDB painting flushes the stuff at the end while interactive
painting flushes while painting.

So everything that would have to be changed is replacing the call
to gimp_paint_core_interpolate() by some_generated_pdb_paint_foo()
and flush the display in between. Not a big deal i'd say.

(What I want to say is that painting has been abstracted well
enough to enable stroke recording without changing too much).

But then you are right, maybe we need a new API because it's
perhaps cleaner to just draw the stuff as we do now and to
create the recorded entry on button_release()

Gimp-developer mailing list

Reply via email to