[already sent off-list by mistake]
At 17:15 23.06.03 +0200, Sven Neumann wrote:
>Hi,
>
>Nathan Carl Summers <[EMAIL PROTECTED]> writes:
>
>>> 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.
>
>When I read this mail, an idea came to my mind that I hadn't thought
>of before. I'm bringing it up here for discussion:
>
>Is the PDB really the right place for a macro recorder? As a user I
>would expect it to be tightly coupled with the Undo system. I would
>want to be able to go back five steps and change the brush I used for
>that paint-stroke, then replay the actions I had performed so far.
>
>But perhaps this just means that the Undo system needs to be hooked
>into the PDB as well ?!  
It would certainly be useful to have that capability. Though if
the user is used to macro recording he would probably be able
to change the brush selction later in the recorded source ...

Probably finally the undo system should deliver it's 'recover 
points' to the recorder and trigger some rollback not only to the
data but to the recorded functions calls as well.

>It could however also mean that macro
>recording would better be implemented in the Undo system. 
Probably not. AFAIS the concepts are simply too different.
The Undo system is required to provide its functionality 
even for irreversible function. It does so by simply using
enough memory.
OTOH the macro recorder needs to see exact functions but is
only interested in the redo direction (minus the point 
mentioned above)

>This would
>also avoid the mentioned problem with PDB functions called from
>plug-ins.
>
I'm not sure if the call stack visible to the macro recorder 
really is more than an implementation detail/problem.
It even could be useful to let the pdb interceptor see all
the functions called - for debugging purpose or to even
translate scripts from language to another: porting
scheme to readable :-)

        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

Reply via email to