Hi,

Hans Breuer writes:

- Intercept every PDB call if a macro recorder instance is running. (try to guess the call stack depth to avoid recording functions called by a plug-in)

That would mean that all actions go through the PDB. The fact is that no user action goes through the PDB at the moment. Only plug-ins call PDB functions, the core doesn't. We definitely need to change this to make macro recording possible.

Now for my questions :
- are there further huge changes planned for the plug-in/pdb code (time involved to maintain my patch) ?

Yes, definitely. The PDB needs to be completely dumped and redone. It lacks such important features as named parameters and default values. Nathan is already working on a replacement library that is supposed to provide that functionality. We should consider to revamp the PDB soon after the release.

- is the outlined approach mature enough to be at least considered for acceptance if I have a first working version ?

We usually prefer if code is developed in the CVS tree. Most attempts where people tried to prepare a working version in their tree lead to rotting bits and wasted time and effort. It seems like the macro recorder needs some substantial changes to the framework. Once these are done, it should be a piece of cake to implement. That said, I'd suggest you help defining and building the framework needed.

Sven

Hi,

Hans Breuer writes:

This is the all-or-nothing argument. IMO a macro recorder would already be useful if it only records the calls done as reaction on users menu usage, where many go through the PDB. Without looking further I thought there are already core functions which work like this, too.

I don't want to disappoint you but besides the menu entries that are installed by plug-ins no GIMP menu entry calls a PDB function. Your macro recorder would miss almost all of the user action unless we change this.

At the moment it's probably easier to use Gerd for macro recording purposes.

Probably I should have choosen my words more careful. Second try:

Are there _short-term_ huge changes planned for the plug-in/pdb code ?

Please define _short-term_. As you know we are sortof feature frozen and are targetting a release in the very near future. We might decide to revamp the PDB as soon as this release is out. I would call that a good chance for huge changes short-term.

But beside the valueable input from Raphael there was no further response/interest.

Well, perhaps not response but surely interest. It's definitely on the TODO for quite some time already.

Sven

On Fri, 20 Jun 2003 16:50:37 +0200, Sven Neumann wrote:

Hans Breuer writes:

This is the all-or-nothing argument. IMO a macro recorder would already be useful if it only records the calls done as reaction on users menu usage, where many go through the PDB. Without looking further I thought there are already core functions which work like this, too.

I don't want to disappoint you but besides the menu entries that are installed by plug-ins no GIMP menu entry calls a PDB function. Your macro recorder would miss almost all of the user action unless we change this.

When I worked on this a bit more than a year ago, I was able to record (some of) the menu entries belonging to the core, such as Layers->Flatten Image, Image->Scale, Image->Mode->... I do not remember exactly how I did it and I think that it was not very elegant, but it seemed to work. I think that I had to modify each core feature separately and add a hook using the GimpScriptRecorder object before the end of each function.

The biggest problem for me was to generate the equivalent PDB calls for brush strokes, gradients, fills, selections, etc. Especially since I wanted these to be scalable (see my comments in bug #51937 for details).

At the moment it's probably easier to use Gerd for macro recording purposes.

This is fine if you want to record a complete GIMP session from the beginning to the end, but this is probably the least frequent usage of a script recorder. I expect that the most common reasons for using it would be:
- to apply similar operations to different images, - to repeat a sequence of operations several times on the same image, - to get a skeleton of a script that you can edit later. Gerd does not solve any of these problems, unfortunately.

Those who do not know what Gerd is can have a look at these links: http://bugzilla.gnome.org/show_bug.cgi?id=51937 http://www.gtk.org/~timj/gerd/
By the way, the last time I checked (end of last year), Gerd was only working with GTK+ 1.2, not 2.x. I don't know if it has changed since then.

-Raphaël

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

Hi,

Nathan Carl Summers 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 could however also mean that macro recording would better be implemented in the Undo system. This would also avoid the mentioned problem with PDB functions called from plug-ins.

Sven

On Mon, 23 Jun 2003, Sven Neumann wrote:

Hi,

Nathan Carl Summers 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.

You're absolutely right! It seems to me that since we already have the undo system in place, and it is called in all the right places, that that would be a better place to put the macro recorder.

But perhaps this just means that the Undo system needs to be hooked into the PDB as well ?!

That could be cool. You could Undo a couple of times, change the source image a bit, and then Redo, and the Redo would call all the appropriate functions again.

This would also avoid the mentioned problem with PDB functions called from plug-ins.

True, although it's really not that hard to implement a call depth tracker.

Rockwalrus

On Mon, 23 Jun 2003 22:40:56 +0200, Hans Breuer wrote:

At 07:01 23.06.03 -0700, Nathan Carl Summers wrote:

On Fri, 20 Jun 2003, Hans Breuer wrote:

(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 ;)

I was able to solve a large part of that problem when I worked on the macro recorder (before I lost it in a disk crash while I was doing a backup). In http://bugzilla.gnome.org/show_bug.cgi?id=51937 I wrote:

: - The script_recorder contains a glist of GimpScriptAction objects : and several variables used for housekeeping. Among these, one : variable pdb_call_depth is incremented every time a PDB call is : started and decremented when the call returns. If the PDB calls : a script, which in turn makes other PDB calls, then only the : first-level call will be recorded.

The tricky part is to check when the call returns, because in many cases it returns immediately while a script is still running. But if I remember correctly, I was able to implement a workaround by adding one hook in script-fu and another one in gimp_set_data(), although I am not sure that I even needed the latter.

I was able to test this by running round-corners.scm, which is an interesting script because it calls another script for the drop shadow, which in turn calls the blur filter. I got the correct call stack and list of PDB calls, with only the first one recorded as a user action (script_recorder->pdb_call_depth was 1).

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.

The format can be very simple. In most cases, the only thing that we need to know is the name of the procedure to be called and the values of its arguments. This is what I had in my GimpScriptAction object. A plain text format with one PDB call per line would already be sufficient, if you want to be able to save this list of calls in a file or to pass it between the core and the plug-ins.

- 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'.
[...]

I would expect the first version of the macro recorder to create non-interactive macros. So it would call all plug-ins (and tools and other functions) in non-interactive mode. Those who want to use different parameters for the calls could edit the Script-Fu code (or Perl, or Python, depending on the output language).

Of course, it would be nice to have the option to make some parts of the script more interactive so that the users do not have to edit the generated script, but I don't think this has a high priority. IMHO, the first interactive feature that should be provided is the ability to adapt a script to an image of a different size. If the image is larger than the image on which the script was recorded, the user should be asked if he wants to run the script with all coordinates scaled up or centered or attached to one of the corners of the image. This would mainly affect things like brush strokes, selections and other tools. Applying this to the plug-ins could be a future enhancement.

-Raphaël

Hi,

Hans Breuer writes:

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 ...

I guess the user would want to save macros out of the Undo History dialog. IIRC, that's also what Photoshop does (since 5.5) and it seems like the logical place. It is sort of an all-time-running macro recorder that you can save scripts from whenever you like.

Sven