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
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
