Automagic Forum

Quite a number of forum posts relate to affecting desktop/launcher items one way or another, or to different kinds of displaying information on same desktop.
Often some kind of workaround is needed, because Automagic doesn't directly talk to launcher, or creation of a custom widget is suggested.
It may be be unknown to some that there exist launchers which provide the Locale API Automagic can use to talk to them, thereby providing a powerful way to affect desktop look and functionality.
One of those launchers is Lightning Launcher. Because some of its features wrt Automagic are not immediately evident, I thought of telling in a few posts how the combination of these two tools can enable a kind of control over the desktop which is virtually impossible using a stock launcher.
But be aware, Lightning Launcher is not a simple launcher. The price to pay for its flexibility is complexity - but I suppose you wouldn't be using Automagic if simplicity was what you're after.

Lightning Launcher functionality can be called from Automagic through the Plugin action. Actions, Scripts and Variables are the functions available through the Plugin action:

After pressing the config bar of Lightning Action, the list of services shows:

Very inconspicuous at first sight, this harnesses a lot of desktop affecting configuration power: any desktop item can take values for many characteristics from a variable. When the value of a variable, bound to a characteristics, changes, the desktop item is updated immediately.
Through that mechanism can Automagic set many aspects, like displayed icon, label, rotation, position, colour and many others.

Screenshots: list of item characteristics which can be bound to variables.

This example shows how Automagic can use Lightning launcher variables, to change the label of a desktop icon, in response to events.

As events I've picked connection to and disconnection from a charger. I want a desktop item to be named "charge" or "discharge".

First, the Automagic flow, with triggers by either event. Of course, having two flows, each with its own trigger, is just as possible - but as the count of flows on my device is considerable, as is the number of flow groups, decluttering the flow list by grouping several together into a single flow helps me avoiding to lose track over those, for the cost of a few extra CPU cycles: The first action determines the reason for triggering the flow, and sets an Automagic variable "power" accordingly: Next and last action simply assigns to Lightning launcher variable "power" the value of Automagic variable {power}. Remember to check the "substitute variables" box, otherwise the literal string "{power}" instead of the value of the variable will be assigned. Now the desktop item must be told to change its label accordingly, by editing its properties. The relevant settings are under the "Bindings" tab:
(screenshot pending)
Oops, ran into screenshot limit of 3

(Insert post or description here: types of desktop items, creating an item)


Now the desktop item must be told to change its label accordingly, by editing its properties. The relevant settings are under the "Bindings" tab: All bindings configured for this item are shown on the configuration page. As there isn't any yet, the box is empty: Adding a new binding, "label" is chosen, which expects a string.
Instead of assigning a static value, the variable "power" is used instead.
Lightning Launcher identifies variables by the leading dollar sign:

hi,

nice tutorial. Thank you !!!

Can you somehow show how to change the icon on the desktop? For example in your "power charging" task?

Undecided, because I focus on Automagic - Lightning Launcher interaction. The principle of writing to a variable "icon" instead of "power" is from Automagic viewpoint identical. The difference is found in the item configuration - that's more a matter for a Lightning launcher tutorial than what I'm striving to show in these posts. That's also why I don't intend to get "fancy" on this power example, like rotating the text according battery charge, or colouring the display - that's just outside of scope. I also risk to get questions asked like "why don't you use an Automagic custom widget for this" (answer would probably be along the line of "why should I have to build a widget, if i can do with a plain desktop launcher object?")

I can give you a few hints, though, how I handle this: depending on whether the item is meant to switch been two or between more than two icons, I pick one or another approach.
In case of just two icons, I create two icon objects, and control the property "z-axis" of one of those through a variable, say "layer". Then I move both items to the same screen position. This approach I choose because only one item needs control through binding.

In case of more than two items, I use the property "display the icon" of every icon object, with a value of "$icon == id" where id is the value (number or string) which causes that specific icon to show. There will be only one object matching, and therefore display the icon. The alternative expressions, for rearranging Z-axis ordering, could be "($icon == id)+2", resulting in 3 for the matching item, and 2 for all others. The higher, the topper.

Another consideration which approach to choose can be how you want the objects to respond to touches: If gestures and actions should be the same for all icon visualisations, control of icon display may be the preferred method, because that way you can keep one object on top of Z-axis, which then deals with user interaction. In case other properties, such as actions bound to gestures, should change too, moving the respective object to top of Z-axis may be more desirable, because that way can each icon provide its own set of responses to user interaction. After all, desktop objects can respond to tap, long tap, 4 ways of swipes, or faster touch (no delay until it can be determined whether a tap was short or long one), apart from pausing or resuming actions. I'm using the Z axis sequence for app launcher, with several similar apps on apparently one button. As a long push gesture switches to the next app, easy configuration of the app on the launcher, while keeping its function group the same, is possible. Examples: choice of navigation apps, choice of star chart app, choice of calculator.

To deal with moving such a multiple object around, it may be practical to place it in its own container (an icon sized panel), which, when moved, moves all contained objects along with it.

Almost a no-brainer, compared to the variable example above: Let Automagic decide what desktop to switch to.
But that what Lightning calls "desktop" may not exactly be what you understand as "desktop" coming from different launcher. Usually, another "desktop" is considered one of those pages to swipe right or left from the home page to. This is NOT what Lightning calls a desktop. Those are, from Lightning viewpoint and terminology, merely "positions" - regions of the same desktop, but outside current view unless moved to.

(Screenshot: desktop full zoom, home position) - the clock is an Automagic custom widget, btw. It's colouring conveys a lot of information. The green bar at top is an Automagic widget too, in its 1 pixel wide overlay, indicating battery charge by its length, and charger state by colour. The menu button at bottom right invokes another Automagic widget.
(Screenshot: same desktop, full zoom but different position) - home position is the only place with desktop items, other than the four locked text-only items in the corners. Most of them switch to other desktops, instantly and void of any transition animation. A very conservative estimation is that about 100 man years are lost every day by needless animations. (Screenshot: same desktop, zoomed out) - The noisy little rectangle is the home position from first screenshot Another Lightning desktop bears no geographical relationship to any other Lightning desktop - one can not pan from one to another, as they are completely separate from each other. They may look similar, but that's only by user choice (by applying the same "profile" to some or all other desktops) - their look and function may also be completely different, as each desktop has its own configuration, can have its own icon theme, color theme, screen grid, script set etc, more like a completely different launcher.

Having Automagic detect that device is used in a vehicle, in the office or at home, and switch desktop accordingly, can therefore present a very different user interface, customised to work best in the resp. environment. The flow for this is so trivial that a screenshot, or step by step instructions, should be completely unnecessary.

(No screenshot for stated reason, which is good because I hit the limit of 3 already)

Ever wished to run a script, written in JavaScript, in response to an Automagic trigger? JavaScript is the scripting language of Lightning Launcher, and their names are also exposed through the Locale API, from where they are available to Automagic for execution.
Scripts can either be written beforehand, imported from external sources, or written on the fly during creation of the Automagic flow. Arguments can be passed to the script from the Automagic action.

(Screenshot: creating Automagic action for executing JavaScript)