On Fri, 20 Jun 2003, Hans Breuer wrote: > I'm about to give it another try with current cvs code > base, but before I would like to get some information > to avoid (if possible) fast rotting bits. > > In short the approach (more info in bugzilla) : > - Intercept every PDB call if a macro recorder instance is running. The cvs version of Libpdb already provides a flexible mechanism for intercepting pdb calls. I designed it with macro recording in mind. > (try to guess the call stack depth to avoid recording functions > called by a plug-in) I had a solution to that problem, but I don't remember what it was anymore ;( > - deliver PDB calling information to the temp_proc installed by > the macro recorder > - extend the Gimp Protocol to allow to deliver typed parameter > information after an interactive plug-in has fininished it's > work. > - long-term : replace the gimp_set_data/run-with-last-values > mechanics with the typed parameter information I'll illustrate the way I imagine this will work with libpdb in an example: Say that the user calls the Gausian Blur IIR plugin. Gimp calls the pdb function gimp_plugin/gaussian_blur_iir/interactive, which returns an argument list with the user's desired parameters. Gimp then calls gimp_plugin/gaussian_blur_iir with the appropriate values. The macro recorder catches the call and records it. Almost all of the work necessary for this situation has been done and is present in the CVS version. > - build a first full blown script recorder in the prefered > scripting language (mine is Python) It would be nice eventually to have a language-neutral frontend that feeds ASTs to the language-specific backends. > - maybe : allow to let plug-ins register default parameters > along with their procedures This would be a good addition. > - use default parameters to reduce 'forced dialogs', i.e. make > them optional. Best example is png-save where the user - at > at least I - almost never changes any values. Sounds nice, but how would the user change the values when needed? > Now for my questions : > - are there further huge changes planned for the plug-in/pdb > code (time involved to maintain my patch) ? Libpdb will be used in the next version of gimp. It probably makes the most sense to concentrate on implementing this functionality there. We have already made a good start on it. > - is the outlined approach mature enough to be at least > considered for acceptance if I have a first working version ? It would certainly be accepted in libpdb. ;) Nathan
