At 07:01 23.06.03 -0700, Nathan Carl Summers wrote: >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. > I took a short look but haven't seen. My simple - not yet working again - approach is to port my original patch to Gimp 1.3. At least as proof of concept. >> (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 >;( > Please try harder, this is one of the problem I currently have ;) >> - 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. > IMO this would require a much bigger change to The Gimp core, cause it would have to guess (or the macro recorder) if this a pdb call should be repeated noninteractive or not. Seems to require the same amount of protocol changes but give more restrictions to the macro recorder which _may_ be interested in getting and providing the interactive calls, too. >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. > Yeah - this may be nice in the long-term sollution - Raphael already mentions it in the bug report. But given that I even don't know what an AST is it won't be in my first version. Instead I was thinking of an xml format recorder and executor as 'languuage independent' first version. >> - 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? > Just an options butto in File Save or even a checkbox which reads 'use defaults'. [...] >> - 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. ;) > The biggest changes required in relation with my patch are not related to the pdb implementaton, but it's usage. - Do more (all) menu actions via pdb - extend the plug-in protocol to allow to get on the 'interactive' values - but only if the user didn't cancel the action. Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert
