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] Exif support
Hi, David Neary [EMAIL PROTECTED] writes: Just to inform peopel who aren't following CVS or Bugzilla, Exif support (of a kind) has been added to HEAD. There's more nice stuff being added to CVS such as a grid and persistent text layers. I will try not to wait too long with the 1.3.16 release... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GAP Filters
Hello ... Where have teh GAP filters gone in the 1.3.x tree? I've found them in the plug-ins-gap in the 1.2.x, and I am intending to modify the filter all layers, to do aply another filter with variable parameters based on the Value information of a mapping drawable. Easy to do, and powerfull enough to make a lot of cool effects. Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP Filters
On Tue, 2003-06-24 at 19:16, Joao S. O. Bueno wrote: Where have teh GAP filters gone in the 1.3.x tree? GAP has been moved to the gimp-gab cvs module. Sincerely, ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Exif support
Hi all, Just to inform peopel who aren't following CVS or Bugzilla, Exif support (of a kind) has been added to HEAD. If you have libexif installed, you can now conserve exif data stored with a jpeg across GIMP edits. There are no interface bells and whistles, no metadata editor, no exif data editor. If the data is there, it's loaded up and associated with the GimpImage, and if it's there at save time (when you're saving as jpeg), it's written out to the output file. This is step 1 in a grand plan (which will probably never get to step 5). 1) Don't destroy exif information 2) Don't destroy tiff/ep information 3) Don't destroy IPTC/XPC information 4) Update all of the data elements directly associated with the image for which there is no extra user interraction required (width/height, comment) 5) Provide a nice way to edit metadata 6) Have metadata associated with layers rather than images, and have a nice way to merge metadata from different sources. Anyone know of a free C library that parses tiff/ep, iptc and xmp data? How about Dublin Core? Anyway, this is just an information email... but if people have ideas for nice external libraries to do the rest of this stuff, they're welcome. Just to preempts the PMT (Picture Metadata Toolkit) suggestion, OpenTIFF and OpenExif are C++ - and do we really want to have Xerces/C++ as a dependency of the gimp for xmp/iptc support? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP Filters
Hi, Henrik Brix Andersen [EMAIL PROTECTED] writes: On Tue, 2003-06-24 at 19:16, Joao S. O. Bueno wrote: Where have teh GAP filters gone in the 1.3.x tree? GAP has been moved to the gimp-gab cvs module. cvs module gimp-gap of course There are inofficial CVS snapshots on http://sven.gimp.org/. But please don't bug me with any problems you might have to compile or run them... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
