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] Two problems in python-fu for gimp 1.3.15
At 23:11 20.06.03 -0700, [EMAIL PROTECTED] wrote: 1. In plugins like whirlpinch.py we have: (PF_SLIDER, whirl, Whirl angle, 90, (-360, 360, 1)), I would assume the second item is the display version and is what should show up in the UI, however whirl is what is displayed in the dialog box. NOTABUG : the first is used as label, the second shows up in the tooltip 2. This crashes gimp; In the python console type: img = pdb.file_jpeg_load(/tmp/file.jpg, /tmp/file.jpg) draw = pdb.gimp_image_active_drawable(img) pdb.script_fu_coffee_stain(img, draw, 3, 0) Partly confirmed. Though for me it does not crash Gimp nor Python but Script-fu ... My first guess that this crash is related to the recent change of the menaing of TEMPORARY procedure appears to be wron. It crashes with gimp 1.3 before that, but work in the 1.2.x version. Calling any script-fu script from python causes a crash. Off topic: What's the reason we have to pass the filename twice for load and save operations? Let me know if I should file bugs on these. Please do for the second issue. Thanks, 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
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
