On Wed, 20 Feb 2002 00:10:16 +1100, "David Hodson" <hodsond@xxxxxxxxxxxxxx> 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 "gimp-path-set-points". > 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 problem. > - 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. -Raphael
