On Fri, Mar 26, 2004 at 06:53:28PM +0100, Michael Natterer wrote: > >> Manish Singh <yosh@xxxxxxxx> writes: > > 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() Right, it wouldn't be hard to adapt the code to do this. But we should nail down a sane API... We could simply bypass the pdb for painting, and just emit "record this" on button release. But maybe it'd be better to have the pdb more involved, I dunno. -Yosh
