Project

General

Profile

Bug #9824

Design Issues for multiple instance copypasting of module settings

Added by asdkant - about 4 years ago.

Status:
New
Priority:
High
Assignee:
-
Category:
General
Target version:
-
Start date:
02/20/2014
Due date:
% Done:

0%

Affected Version:
1.4.1
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

If I copy settings from an image with multiple instances of a module A into another image with a different amount of instances of that module there is no obvious behaviour of what's going to happen. This is a HUGE problem when one starts scaling the amount of instances.

Example: I had to add a second watermark to a batch of images. My usual watermark varies depending on the image, but this second one would be always the same. I found kind of a workaround that consisted of copying the history stack steps for the two instances... but that overwrites the settings for the first watermark, which I want to keep as they are different for every image. If I copy only the step for the second instance, it pastes on the single instance of another image; in this case I want to create a second instance on the second image and paste the settings for the second instance on the first image, but that is not a universal, maybe someone would want the current behaviour.

Another use case:
image A, 5 instances of the module
image B, 3 instances of the module

User wants to copy instance 2 of image A and paste it on instance 1 of image B. There's currently no way to specify where the pasted settings go, just a non obvious behaviour determined by the program.

possible UX to solve this:
  • if there's no multiplicity of instances, just keep the basic behaviour
  • in the presence of multiple instances in the list of settings to copy, show a UI (drag & drop maybe?) asking the user to match instances in the source image to instances in the destination image. default could be the stacking order
  • user could assign names to instances, when copying a single instance to an image with multiple instance, the default could be the instance with the same name (example: "first" and "second" for the previous watermark example). If not present, default to a specific end of the stacking order of the instances.

Related issues

Related to darktable - Feature #9779: Some way to store&auto-apply multi-instance presets? Triaged 01/17/2014

History

#1 Updated by Roman Lebedev about 3 years ago

  • Related to Feature #9779: Some way to store&auto-apply multi-instance presets? added

Also available in: Atom PDF