After having upgraded to v2 (Pro) two years ago (go figure), I finally needed Retrobatch last night and have some feedback (though not all of it may be specific to v2). But first of all, thank you for a tool that, when I need it, really makes a huge difference!
Like several other users, I find the new user interface somewhat of a regression. Always having node properties visible made building and editing workflows simpler and faster, with less clicking around. That seems far more important to me than having a huge preview image.
I’m not sure when you introduced the Multi-Scale node but I love it. It replaced what used to be about 10-15 nodes in my typical workflow. Having said that, all settings for the node, in my use case, differ solely in image width (for responsive images). So the UI for the settings is too general in my use case. It would be nice to have a more concise presentation in case all settings are the same modulo image width or height etc.
Retrobatch appears to use an alias for folders, so even if I move the folder, it will use the folder. That’s generally great. Alas, when I trash a folder, that doesn’t seem so great anymore. Worse, if I now empty the trash, Retrobatch will recreate the folder inside the trash. That seems like the wrong place.
If you want to go the extra mile, Retrobatch should probably warn users when saving the workflow file to the same folder as generated images. The latter are trivially recreated with a workflow, well, as long as I didn’t delete the workflow with the images… (Thankfully, I realized my mistake before emptying the trash.)
Finally, one question: Is there a way to turn a sequence of nodes into a library building block? I keep recreating the same Read Files/Delete Metadata/Change Color Profile/Change Bits Per Channel/Remove Color Profile sequence and, just maybe, it’s time to standardize that part…
Thanks for the feedback on this (and thanks to everyone else as well). I definitely want to keep improving things in this area.
I’ll see what I can do in a future release. If you have a quick mockup of what you’re thinking, that would help too.
Yeah, that’s not great. Aliases (also known as the “Bookmarks API” these days) are required for storing user intent and working with security-scoped permissions. So I’m stuck using that API, but I’ll look into having RB show a warning if it detects the output folder is in the trash. (Though I suppose that could be a legit use case in some weird situations!)
“Patches” is what I’ve been calling them, and while RB can’t do that yet, it’s definitely on the to-do list.
If you have a quick mockup of what you’re thinking, that would help too.
Actually, you might be able to get away with no UI for this feature, simply by allowing for several comma-separated values per field. That’s as concise as it gets. It also generalizes: If more than one field has more than one value, it means all combinations thereof. Discoverability would require something like a suggested completion or tooltip being shown—or a tour upon first launch. Then again, Retrobatch Pro already supports JavaScript expressions in fields, so maybe this isn’t as critical.
Aliases (also known as the “Bookmarks API” these days) are required for storing user intent and working with security-scoped permissions. So I’m stuck using that API
Ooh, does that mean that the Bookmarks API can be (ab)used to resurrect a folder over and over again even after trashing? If so, maybe zombie folders are a good way of encouraging Apple to fix the behavior of bookmarks…
The API won’t create the folders, RB will figure out where it last was, and then create it from there. So, it’s not a security problem on Apple’s end.
