On Mon, 23 Jun 2003 22:40:56 +0200, Hans Breuer <Hans@xxxxxxxxxx> 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
