Shortcut trigger variables

[Bushmills]

I don't know whether this request requires cooperation of the application - often a launcher - invoking the shortcut. Currently it seems that even if such an app wanted to cooperate, there appear to be no provisions for passing the invocation method and reason to the Automagic shortcut, which in turn makes those available to the flow, in form of variables.
Currently, i don't seem to have any other way to know about how a shortcut was invoked (like: from a launcher desktop object - icon label passed to shortcut too - , by single tap/long tap/double click/wipe up, down, left, right, for by Automagic action "Excecute flow", Manual execution, and all the ways to launch the action assiciated with a shortcut). {trigger} only carries information that flow was launched because of Shortcut - as if I didn't know.
This usually means that for each kind of activation, a new flow / shortcut trigger is needed, in order to react to the context of invocation. This also means that each individual flow must be bound to every invocation method, making this hard to maintain, compared to ...:

Were flows able to derive the method of invocation from trigger variables, as well as additional information - such as label of invoking desktop icon - the same flow could be bound to many invocation methods: What needs to be done could be determined by the flow, such as, whether it needs to respond to a single tap to a desktop object, a clickable field of a widget, or the custom button of an application.

Whether Automagic can provide that information depends of course on whether it is avaiable to Automagic. Trying to establish a bilateral convention between other applications and Automagic is probably doomed to become a fruitless endeavor. But - and that part is beyond my knowledge - maybe Android gathers that kind of information already, free to take and provide, in which case the Shortcut trigger should.

[Martin]

Flows invoked by custom widgets already get some additional variables (like gesture, widget_cell, widget_name). You can also check the variables and values by adding a condition Debug Dialog to the flow.
For shortcuts you only get the name of the trigger. I'll check if there's more information available from the launcher that could be passed on to the flow.

[Bushmills]

Thank you. Yes, custom widgets are more flexible, I find widget_cell_x and widget_cell_y very useful in that respect, which I in turn use to read gesture-area specific data through getWidgetElementProperty, Unluckily can custom widgets, unless they are displayed on an overlay, not respond to other gestures than simple clicks, and my attempts of showing/hiding the overlay with the custom widgets as enhancement to the desktop wasn't entirely satisfactory, because of the involved lag between bringing launcher to foreground until overlay placed, and vice versa, between launcher backgrounded until overlay removed. So in fact my request addresses exactly that - provide similar gesture functionality while avoiding the custom widget overlay.
A screenshot of a flow, bound to every clickable field in a 5x4 buttons custom widget, looks like this. It sort of emulates the "desktop object label" information by reading it from the widget text field.
In other widget implementations, I resort to invisible text fields to carry information. allowing me to achieve exactly what I wish the desktop version to be able to: a single flow
to rule them (pesky desktop objects) all. The custom widget which binds the flow is shown below.

Screenshot_2016-05-17-21-00-17.png (125.62 KiB) Viewed 8895 times

Screenshot_2016-05-17-21-11-49.png (199.67 KiB) Viewed 8895 times