On Wed, 20 Feb 2002 00:10:16 +1100, "David Hodson" <[EMAIL PROTECTED]> wrote:
> Raphael Quinet wrote:
> > - Use the PDB for all interactive tools.  All actions that can be
> >    performed by clicking somewhere in the image window (painting,
> >    selecting, picking a color, moving guides, panning, zooming, ...)
> >    must be able to trigger a PDB call.
> To avoid horrible amounts of overhead, I'm guessing that it should
> be enough (in most cases) to trigger on button up, and send a vector
> of cursor positions.

Yes.  When the mouse/pen button is released, it should generate an array
of strokes, suitable to be used by "gimp-paintbrush-default" or
"gimp-paintbrush".  Similar things can be done with the paths, for

> From the other side, can users define their own interactive tools?
> (How do they get added to the toolbox?)

That should probably be done with a module, but how to add the tools to
the toolbox has not been discussed yet, AFAIK.

> > - Use named parameters for the PDB.  Instead of using positional
> >    parameters, all PDB calls could take a list of name=value pairs, in
> >    which each name is a string.
> Would it be too much work to provide a separate call interface for
> this style, and keep the old interface?

Well, maybe.  I was hoping to start a discussion about that, but it looks
like my attempt was not very successful, considering the amount of
feedback received so far (only one message).

> - Allow plugins to intercept the progress callback (and replace the
> progress indicator).

That should not be too hard, if a separate function is provided for that.
This would not affect the existing plug-ins, so it should not be a

> - Allow (force?) plugins to provide default values and valid ranges
> for parameters. (And for floats, precision / number of decimals).

This, on the other hand, is something that would break the existing
plug-ins.  This is a good idea.  But sometimes the valid ranges are not
fixed, because the valid range for one parameter may depend on what has
been selected for another parameter.

> - I'm thinking about some applications in which I would like to be
> able to open a display and restrict what users can do on that display,
> but at this stage I'm still a little vague on this. Maybe if they
> couldn't change tools on that display ... I'll have to think about
> this.

That could be a bit tricky and would require some changes in the core,
but hopefully this can be implemented in a way that does not break the
existing plug-ins.  What I was trying to do with my previous mail is to
start a discussion about the features that will almost certainly require
some changes in the existing plug-ins, and maybe to decide if/when this
should be done.

Gimp-developer mailing list

Reply via email to