Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

duplicant transparency mode #80

Closed
Tracked by #48
plastikfan opened this issue Dec 21, 2023 · 0 comments · Fixed by #81
Closed
Tracked by #48

duplicant transparency mode #80

plastikfan opened this issue Dec 21, 2023 · 0 comments · Fixed by #81
Assignees
Labels
feature New feature or request

Comments

@plastikfan
Copy link
Contributor

plastikfan commented Dec 21, 2023

The term duplicant is not a real word, rather, it is a rif on duplicate, but duplicate is not adequate because it implies a copy of. The concept that duplicant represents is the fact that when pixa runs in a mode where multiple results are created for each input file, each of these are a duplicant of the original (not a duplicate). And just to be clear, a duplicant can only be created when mutiple results are created. So this either means a full or sample run is executed where a scheme is referenced, which contains more than 1 profile.

Transparency mode for duplicants can't really exist, because transparency mode always refers to the idea that the file system remains the same as it did before pixa was run except that input files are replaced inline by the output and the input is placed elsewhere. This means that to clean up, the user needs to delete files in alterntive locations (either a central trash location or inline trash location). Having said this, what we can say for duplicant transpancy mode, it might be admirable so always create result files in the same location as the input, to make it easy to compare input and resultant files. To combat the obvious clash in names, result files need to be decorated with an appropriate tag which would be an amalgam of the <scheme name>/<profile>/ADHOC.

The destination for the input is transparent if --trash has not been specified. The destination for the input file should be renamed to the origin path (item.Parent) + item.Name + an original file tag, eg "INPUT". So for example:

  • item.Name: 01_Backyard-Worlds-Planet-9_s01.jpg
  • destination: 01_Backyard-Worlds-Planet-9_s01.INPUT.jpg

The path finder should have a new method Yield_ which represents an output and is equivalent to the Destination method for the input.

Another requirement that emerges from this issue is that the TRASH location is only used if not in transparent mode. SO transparency has is separate effect on the INPUT and yields (or duplcants). It also means that transparent can't be set explicitly, it is derived by the presence of --output (which applies to yield) and/ or --trash (which applies to input).

On further thought, it may be better to drop th duplicant terminology, it will only end in tears! So instead create a Result method on path finder which accpets resultInfo containg fields that allow it to return the result path for a result in the same manner that the Destination method does. It will apply to the duplicant scenario already described and a single output result.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant