type=file is ignored when variables are also set [Changes made for 3.4.1 b858 pre-release]

[deanishe]

Alfred 3.4 (850)

 

type = file is ignored on feedback items when workflow variables are also set via arg (i.e. arg is a JSON-encoded alfredworkflow object).

 

Run the following workflow or build your own Script Filter around the JSON feedback. You can hit right-arrow on the first item with a "plain" arg to access File Actions. File Actions don't work on the second item, however.

 

Demo workflow.

 

Script Filter feedback:

{
  "items": [
    {
      "title": "Path, no vars",
      "subtitle": "This works with File Actions",
      "type": "file",
      "arg": "~/Desktop"
    },
    {
      "title": "Path, with vars",
      "subtitle": "This doesn't work with File Actions",
      "type": "file",
      "arg": "{\"alfredworkflow\": {\"variables\": {\"var1\": \"val1\"}, \"arg\": \"~/Desktop\"}}"
    }
  ]
}

 

Edited June 25, 2017 by deanishe
File Actions, not File Filters

[Andrew]

@deanishe if you set type as file, then Alfred expects a file in the arg and will check if that file exists before treating it as a file.

 

It's interesting seeing how you are setting variables per item there by essentially passing JSON as the arg. Makes me think that there is a case to have a "variables" field per item so that you can continue to use the arg for the actual argument, making this scenario work as expected. (Assuming you specifically want vars only set for this one result, and not globally for the script output, which would be done in the variables field).

 

You can actually set the type to "file:skipcheck" to get Alfred to skip the existence check, but I'm not sure the file actions panel will work with JSON as the arg (not currently at my Mac to check this).

 

Cheers,

Andrew

[deanishe]

55 minutes ago, Andrew said:

It's interesting seeing how you are setting variables per item there by essentially passing JSON as the arg.

 

That's the way you built it…

 

I do this all the time with Alfred 3. It's a core feature of Alfred-Workflow and extremely useful for avoiding ridiculous numbers of elements in Alfred.

 

In particular, command-line libraries like Click, Cobra and Kingpin allow you to automatically map environment variables to command-line options.

 

That's a fantastic combination and lets you avoid a lot of duplication (i.e. adding a bunch of mostly-identical Alfred elements for every single action).

 

(We've spoken before about the utility of being able to control execution flow from code instead of workflow elements, and this is a good way to do it.)

 

1 hour ago, Andrew said:

a case to have a "variables" field per item so that you can continue to use the arg for the actual argument, making this scenario work as expected.

 

From my perspective (I've already written the code to do it this way), I'd be happy if Alfred just parsed the alfredworkflow object in arg before doing the is-this-a-file test.

 

That's what I consider a "bug", seeing as that's the official way to set variables from an item and I am passing valid paths as the arg encoded within the alfredworkflow object.

 

But overall it would be simpler if there were a variables object within each item: having to insert JSON as a string within another JSON object is tricky, non-intuitive and not exactly elegant.

 

In that case, mods would also need a variables key. And I believe it's also possible to pass other useful stuff via the alfredworkflow object, such as configurations for downstream File Filters (I've never tried this myself).

 

1 hour ago, Andrew said:

You can actually set the type to "file:skipcheck" to get Alfred to skip the existence check, but I'm not sure the file actions panel will work with JSON as the arg

 

With file:skipcheck the File Actions list opens, but Alfred passes it the JSON, not the arg extracted from it

 

[Andrew]

@deanishe this isn't a bug as you are setting the arg type as file, and then passing JSON as the arg. This is a strict mapping as knowing that a result is a file has a number of behavioural differences for a specific result row (display, navigation, actions, accessibility). Alfred doesn't process any result arguments until they are selected and passed out of the workflow object, at which point, the workflow framework takes care of recognising and processing the output. This is important from a performance standpoint and it also ensures that outputs from all object types are processed in the same way.

 

The fact that you can't set the type as file, AND dynamically set variables by passing JSON out of the argument is a limitation of the Script Filter JSON/XML design. I've raised a ticket to have a look at this, but it will likely be by adding in variables for each item.

 

I've also joined it to my other improvements tickets in this area which will likely be dealt with at the same time (e.g. different icons for mods).

 

Cheers,

Andrew

[deanishe]

1 hour ago, Andrew said:

you are setting the arg type as file, and then passing JSON as the arg

 

I'd say that's a matter of interpretation. From my point of view as a workflow developer, I'm setting a filepath as the arg within the alfredworkflow object. After all, that—and not the JSON—is what Alfred passes as {query} to downstream elements, such as the Debug utility in the workflow I posted.

 

That Alfred passes a different value to File Actions (and ⌘C) than to downstream elements when arg is a JSON-encoded alfredworkflow object, rather than a simple string, strikes me as a quirk of the implementation.

 

1 hour ago, Andrew said:

Alfred doesn't process any result arguments until they are selected and passed out of the workflow object

 

Why does passing arg to the File Actions list (or copying it) not count as being passed out of the workflow object?

 

From my perspective, my workflow is done at that point, and there's no situation where Alfred not decoding the JSON would be the preferred behaviour.

 

This seems to be an implementation detail, not a user-facing feature. In terms of performance, I don't think Alfred would ever need to decode more than one JSON object at a time, would it? I can't perform any actions on multiple items at once.

 

2 hours ago, Andrew said:

it will likely be by adding in variables for each item

 

That's cool. I'd just like to be able to use different Alfred features together that aren't logically incompatible. Now I have to choose whether to forget about File Actions in my workflow or back out a whole bunch of changes and move back to the way it worked under Alfred 2.

 

And as noted, JSON-within-JSON is a bit funky.

[Andrew]

@deanishe Alfred's result view architecturally has no concept of workflows or where actual results have come from. When you perform a cmd+c, add to the buffer, or navigate into a folder for the selected result etc, Alfred understands that a result arg has been marked as a file (from any source, not just script filters), and file interactions are made available.

 

When, in your script filter, you mark the result arg as a file, you are telling Alfred's result view that the argument you have provided is a file, and thus make the file interactions available. Results shown in Alfred are unprocessed, the arg is just a dumb string. This is where the high performance comes in, as Alfred doesn't need to process any of the args BECAUSE of the 'type' defining a result arg as a file.

 

Don't forget that the JSON you are setting in the arg is {"alfredworkflow":...}. It is specifically processed when a result is actioned for the connected outputs in for the workflow, which is why you are seeing it unprocessed when using non-workflow file interactions from Alfred's default results.

 

I can totally appreciate your point of view, but as I've said, the 'type' was added to define the type of the 'arg', and this is a strict relationship to allow Alfred's result view (unaware of workflows), to process the provided arg appropriately.

 

There are a few ways for this to be fixed:

 

1. I'll almost certainly be adding variables for each item in the JSON, which is the correct way to address this issue.

2. Adding a new item 'type' which is something like 'JSON containing a File arg'. This would allow the Script Filter to identify and pre-process items into Results differently. It's unlikely that this would be prioritised above other features.

 

Remember that there is a holistic aspect to look at when it comes to Alfred, where performance is absolute key and a huge priority for me. You've spotted a limitation of the JSON / XML which is the result of an absolute design decision which has just come up for the first time. I'd rather fix this properly than alter architectural design for a less than 1% workflow specific use case.

[deanishe]

4 hours ago, Andrew said:

the 'type' was added to define the type of the 'arg', and this is a strict relationship to allow Alfred's result view…

 

You, as the only person familiar with Alfred's internal workings, have a different understanding of what arg is versus the rest of us for whom Alfred is a black box beyond its publicly-defined APIs.

 

Totally agree that adding variables (and config) to items and mods is the right solution. That's way cleaner.

 

4 hours ago, Andrew said:

Adding a new item 'type' which is something like 'JSON containing a File arg'. This would allow the Script Filter to identify and pre-process items into Results differently. It's unlikely that this would be prioritised above other features.

 

I don't think that's a very good idea.

 

TBH, I don't believe that checking for JSON, and decoding it if necessary, when the user hits the File Actions/Add to Buffer shortcut or presses ⌘C/⌘L would affect Alfred's performance in any perceptible way. As noted, these actions only apply to single results, and the test+decoding takes milliseconds for a single item.

 

I can understand that it messes with the architecture, however.