Re: [Gimp-developer] Macro Recorder 2nd Try
[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
Re: [Gimp-developer] Macro Recorder 2nd Try
On Mon, 23 Jun 2003 22:40:56 +0200, Hans Breuer [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Macro Recorder 2nd Try
Hi, Hans Breuer [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Macro Recorder 2nd Try
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 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Macro Recorder 2nd Try
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
Re: [Gimp-developer] Macro Recorder 2nd Try
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Macro Recorder 2nd Try
Hi, Hans Breuer [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Macro Recorder 2nd Try
At 15:20 20.06.03 +0200, Sven Neumann wrote: Hi, Hans Breuer [EMAIL PROTECTED] 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. 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. Obviously the recorder should be written that every function which finally goes through the PDB gets recorder as well. But it would be rather difficult to _not_ make this happen automagically ... 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. Probably I should have choosen my words more careful. Second try: Are there _short-term_ huge changes planned for the plug-in/pdb code ? - 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. Agreed, been there doen that ;) OTOH before putting something into cvs it should basically work, which my original patch against gimp-1-2-cvs did - at least it did not break anything else. 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. That's what I tried with my additions (half a year ago) to http://bugzilla.gnome.org/show_bug.cgi?id=51937 But beside the valueable input from Raphael there was no further response/interest. Sven 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
Re: [Gimp-developer] Macro Recorder 2nd Try
On Fri, 20 Jun 2003 16:50:37 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hans Breuer [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
