"Ready for web" workflow

[pnomolos]

Hi there!

This is all on Retrobatch 2.0.1 with a Pro license.

I have been refining my workflow for getting images ready for web, and my ultimate goal is something like this:

1. Select folder/individual images to process (this one is fine with the current nodes)
2. Select the outgoing folder (Currently attempting to do this in JS via NSOpenPanel) and store that value for later use.
3. Process images as required.
4. Write out images. Current ideal workflow would be four variations (1x and 2x, webp and png/jpeg) all to the folder that was previously selected (and perhaps a subfolder for each variation). This is also do-able with the current node system and the process outlined here: Filename writing from regex - #3 by ccgus - I just need some way of properly getting that folder value

I’d love any input or suggestions on what I could do to improve the process. One of the keys is that the input and output folders need to be flexible as those are changing all the time (input is less-so, but definitely the output folder). I would really like not selecting the output folder once for every variation of scale and format.

Also a couple of suggestions:

1. The workflowStart function seemed to be firing as I was editing the workflow itself. My assumption was that it would only fire when the play button was pressed. If this is unexpected behaviour I can post a video showing what’s going on.
2. It would be really nice if you pre-emptively catch that you’re calling something like NSOpenPanel.new().runModal() outside of a DispatchQueue.syncOnMain callback, as things get real funky when you accidentally do that.
3. A button to clear the console would be great
4. A checkbox to “clear console on workflow start” would be even more awesome for debugging

Thank you so much, though, Retrobatch has already saved me a ton of time

[ccgus]

Hello and welcome!

I really like this idea, and I have something for you to try below.

@pnomolos

1. The workflowStart function seemed to be firing as I was editing the workflow itself. My assumption was that it would only fire when the play button was pressed. If this is unexpected behaviour I can post a video showing what’s going on.

This will happen when Retrobatch is trying to load a preview. It’s necessary right now, but I’ll see if I can make it less annoying in the future.

2. It would be really nice if you pre-emptively catch that you’re calling something like NSOpenPanel.new().runModal() outside of a DispatchQueue.syncOnMain callback, as things get real funky when you accidentally do that.

This would be very very hard for me to do, and as Apple adds new APIs (or changes them), I’d have to update some sort of allow list. Maybe if there was a second function named along the lines of workflowStartMT (MT for main thread) and everything would be called on the main thread there? Deadlocks are your problem then?

3. A button to clear the console would be great
4. A checkbox to “clear console on workflow start” would be even more awesome for debugging

These I can probably get done.

OK, so here’s something to try, with the disclaimer that this might change and I want feedback on how this works for you.

First up, grab the latest build: https://flyingmeat.com/download/latest/#retrobatch

Next up, in your JS Node, you can put in something like this:

fjsimport("UniformTypeIdentifiers");

var myWriteFolder = null;

function workflowStart(document, jsnode) {
    DispatchQueue.syncOnMain(function () { 
        
        var panel = NSOpenPanel.openPanel();
        panel.setAllowedContentTypes([UTTypeFolder]);
        panel.canChooseDirectories = true;
        panel.runModal()

        console.log("Found: " + panel.URL());

        myWriteFolder = panel.URL();
    });
}


function processAsset(document, jsnode, asset) {
    asset.setUserValue_forKey(myWriteFolder, 'write.outputFolder');
    return true;
}

My test Workflow looks like this:

So the Prompt node will ask for files, and then the JS node will assign a little magic user value which the Write node is looking for. If present, it will then use this for the output folder. This is the new bit I’ve added in the latest build.

I’m not 100% convinced this is the best way to do things, but it’s something to get started with. Let me know when you’ve tried it and how it works out for you.

-gus

[pnomolos]

That seems to be working, although you will have gotten a whole bunch of crash logs from me . I’m not sure, but it appears that if you have a disabled node (in my case, a disabled “Scale to 1100px along long edge” node) right before a Javascript or JS Plugin node, something’s going on.

workflowStart running whenever a preview is generated is definitely an annoyance in this case, because the folder dialog pops up whenever an adjustment is made to the workflow. Could workflowStart pass an additional parameter indicating whether it’s in “previewMode” or not? That seems like the simplest way to extend without breaking existing plugins.

That, or if a plugin defines workflowStartPreviews or workflowStartNoPreviews (or whatever, naming is hard) then workflowStart isn’t called?

[ccgus]

@pnomolos

That seems to be working, although you will have gotten a whole bunch of crash logs from me . I’m not sure, but it appears that if you have a disabled node (in my case, a disabled “Scale to 1100px along long edge” node) right before a Javascript or JS Plugin node, something’s going on.

I’ll check that out - thanks for sending in the reports.

I’ve added a “context” method to the jsnode object that’s passed into the various functions. you can then call isPreviewProcessing() on the context to find out if what’s happening is a preview or not.

You can also now call console.clear() and that’ll do what it says. Or you can paste this in Terminal.app:

defaults write com.flyingmeat.Retrobatch clearConsoleOnWorkflowRun 1

Here’s an updated version of the JS:

// console.clear();
fjsimport("UniformTypeIdentifiers");
var myWriteFolder = null;

function workflowStart(document, jsnode) {
    if (!jsnode.context().isPreviewProcessing()) {
        
        DispatchQueue.syncOnMain(function () { 
            
            var panel = NSOpenPanel.openPanel();
            
            panel.setAllowedContentTypes([UTTypeFolder]);
            panel.canChooseDirectories = true;
            panel.runModal()
            
            myWriteFolder = panel.URL();
            
        });
    }
}


function processAsset(document, jsnode, asset) {
    asset.setUserValue_forKey(myWriteFolder, 'write.outputFolder');
    return true;
}

You’ll need to download the latest version from the previous link, and grab build #1412 (or later).

[pnomolos]

Ah, fantastic! Thank you for being ridiculously quick on those updates, really helpful!

Also, please let me know if you have any more questions about those crashes I was seeing. They seemed to be pretty reproducible so I can probably make them happen again.