After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 753740 - Why doesn't GIMP have a "follow-me" mode for creating repetitive operations?
Why doesn't GIMP have a "follow-me" mode for creating repetitive operations?
Status: RESOLVED DUPLICATE of bug 51937
Product: GIMP
Classification: Other
Component: User Interface
2.8.14
Other Mac OS
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2015-08-18 02:56 UTC by Nicholas Spies
Modified: 2015-08-18 18:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicholas Spies 2015-08-18 02:56:37 UTC
Perhaps I am missing something, but it seems to me that since GIMP maintains enough state to provide a history to enable undo to some arbitrary level, it should be relatively easy to enable the user to bracket part of that history, copy it, name it, and perhaps edit it, to perform repetitive operations without it being necessary, at least in most cases, to have to resort to an explicit scripting language such as Script-Fu or Python-Fu to perform repetitive operations.

This would be very much like the ability to capture a set of keystrokes in Emacs and then repeat them over and over again, either having named them for reuse or by using keystrokes to repeat the most-recently-defined sequence.

Many manual operations bring up a dialog box into which parameters are entered. By using the history replay method, the parameters originally entered would appear in the dialog, where they could be simply accepted with an OK or changed, if they needed to be changed, by editing the dialog values.

The main challenge, I would think, would be to apply a recorded series of events applied originally to one window or picture to another window, in an orderly manner.

My application, manipulating stereo pairs of images, would become far easier than is presently the case. Here is an example of the operations required:
1. Open the left and right eye pictures.
2. Determine (if necessary) which picture is L and which is R -- done my viewing
3. Determine which type of stereo pair is needed (L-R, R-L or anaglyphic)
3a. L-R is for viewing with a pair of lenses
3b. R-L is for viewing cross-eyed without need of any extra equipment
3c. Anaglyphic decomposes L and R into layers; red is taken from L pic while green and blue are taken from R pic. This is done by cutting and pasting layers and then composing a red-cyan color picture, viewed with red-cyan glasses
4. Depending on step 3...
4a. Make L-R picture by the following steps:
4a1. Resize L picture width 200% with all layers selected
4a2. Resize R picture width 200%, move picture to right, with all layers selected
4a3. With R picture, make white transparent
4a4. Copy R picture and paste onto left; make a layer from clipboard
4a5. Move up/down to make key features in both halves on same horizontal (manually)
4a6. Save the resulting pair, as GIMP file with layers intact
5. For R-L pair, follow steps in 4, but with L and R pic in reverse order
6. For anaglyph stereo...
6a. Decompose both L and R pic into B&W RGB layers
6b. Use R pic as basis: cut red layer out; replace with red layer from L pic
6c. Recompose layers to make red-cyan color pic to view with red-cyan glasses

Clearly, in the above, a great deal of time could be saved by a "follow-me" type of automation. In each case, the resultant scripts would be named, and "aimed" at one or the other of the L and R pictures, changing parameters, such as would be needed for steps 4a1. versus 4a2.+4a3.

The whole process would be conducted within the GUI, without recourse to any programming. The result would be a series of named sub-tasks that could be put into the Filters menu and would apply to the selected picture. Running these would be like replaying the actions originally "recorded", with the possibility to change parameters (at a minimum) or with parameters pre-entered as appropriate for the actions called for for each picture, given the desired result. In any case, the named replays would be capable of being called from within scripts to allow for finer-grained editing.
Comment 1 tobias 2015-08-18 08:06:21 UTC
Hello Nicholas,

thanks for posting this bugreport. This is not as easy as it looks at the first place and discussed since years. 
This is a duplicate of bug #51937.
Comment 2 André Klapper 2015-08-18 18:44:32 UTC

*** This bug has been marked as a duplicate of bug 51937 ***