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
>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 "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert
Gimp-developer mailing list

Reply via email to