Jump to content
deanishe

Script filter result upstream variables missing when using mod variables [Fixed 3.7 b931 pre-release]

Recommended Posts

Alfred's default handling of workflow variables set by modifiers is … odd.


Setting variables via Script Filter feedback at the top level and via items behaves sensibly, and as you might expect. Namely, they are merged with existing variables, overwriting any of the same name.


Setting variables via mod does something completely different. If you set any variables via a mod all other variables created during the execution flow (i.e. set anywhere but in the configuration sheet) are dropped on the floor. Not just top-level variables, but also pre-existing ones set upstream via Args & Vars or a Hotkey or passed in via an External Trigger.


This is counter intuitive, counter to the way variables set elsewhere work, and I don't see an actual use case for mods to behave that way. It's fine that variables set by item the mod belongs to are not set when a mod is used, but top-level variables should not be ignored, imo, and existing variables from upstream should definitely not be deleted.


I would suggest that mod variables should be handled the same way as item variables and be merged with top-level variables and existing variables from upstream.

Share this post


Link to post
Share on other sites
5 hours ago, Andrew said:

this totally sounds like a bug

 

The deletion of upstream variables made me think the same. I figured I'd put it in Feature Suggestions in case anyone else wanted to chime in regarding how mod variables should be handled.

 

Specifically whether they should also be merged with the variables belonging to their parent item or whether the item's variables should be ignored when a mod with variables is used. I would prefer the latter—mod vars replace item vars and aren't merged with them (but that raises the question of what should happen if an item has variables set, but its mod doesn't…)

 

My motivation for that is that my libraries implement creation-time variable inheritance on item and mod and merging a mod's variables with its parent item's would break that, although I'm not sure how many workflows rely on that behaviour. It does have its uses, however.

Edited by deanishe

Share this post


Link to post
Share on other sites

@deanishe I'm currently fixing this for 3.7 and this is a tricky decision. The current behaviour (wether right or wrong) passes the item variables if no variables are set for a mod.

 

As this has only just come up, I think to have the least amount of regression issues would be to do keep the current behaviour, but do as you suggest and the mod variables completely replace item variables (but correctly fixed to override upstream vars etc).

 

I'll also update the documentation to reflect this, as it states:

 

Quote

It is also possible to set additional variables for each mod object within an item. Variables set for a mod will override any item variables of the same name.

 

Which isn't correctly working anyway.

Share this post


Link to post
Share on other sites

Hm, I've tested this fix both ways - It feels more predictable / correct to take the inheritance approach, so if you set variables on a mod, then they are merged in with the item variables (and above), and are overridden where appropriate.

 

If you didn't want a mod to inherit the item variable, it could always be set to empty... or for dynamic inheritance in your library, skip the item variables altogether and just set them on the mods (once the bug is fixed).

Share this post


Link to post
Share on other sites
18 hours ago, Andrew said:

If you didn't want a mod to inherit the item variable, it could always be set to empty...

 

Sure, but empty isn't the same as unset.

 

18 hours ago, Andrew said:

or for dynamic inheritance in your library, skip the item variables altogether and just set them on the mods

 

But then the item has no variables… By merging mod variables with item variables, you'd lose the ability to set a variable on an item but not its mods.

 

I agree that merging is probably the more correct behaviour. I'd prefer mod-replaces-item, though, because that won't break my libraries and workflows. (My issue is with upstream variables getting deleted when a mod is used.)

 

Share this post


Link to post
Share on other sites
1 hour ago, deanishe said:

By merging mod variables with item variables, you'd lose the ability to set a variable on an item but not its mods

 

This behaviour is currently broken too though - If you set item variables and don't set any mod variables, the mod gets the item variables anyway (which is synonymous with the inheritance approach).

 

On the flip side of this, if the mod variables inherit from the item variables, then you can set one variable for the result shared by the item and all the mods, then either override that variable in the mod, or set a separate variable so you know which mod has been used down stream. This feels like the correct behaviour.

 

Is losing the ability to set a variable on an item but not the mods really an issue in practice?

Share this post


Link to post
Share on other sites

Right, I've slept on this and I'm gonna keep minimal disruption here and treat mod override results at the same inheritance level as the result itself... so if you have variables set on a mod, it will fully replace the item variables. I accept that this gives the maximum flexibility of allowing separate variables for an item and a mod.

 

Conveniently, you can also just set variables": {} on a mod if you don't want it to take the item variables by default.

 

Cheers,

Andrew

Share this post


Link to post
Share on other sites
On 8/21/2018 at 10:52 AM, Andrew said:

Is losing the ability to set a variable on an item but not the mods really an issue in practice?

 

It would break a few of my workflows for sure. I often use this idiom (see the last lines of the code sample).

 

22 hours ago, Andrew said:

Right, I've slept on this and I'm gonna keep minimal disruption here and treat mod override results at the same inheritance level as the result itself

 

Thanks. That seems likely to break the least stuff.

Share this post


Link to post
Share on other sites

×