Order of operations

[FelixKratz]

A fundamental problem in lua is that the key value tables are not sorted. This means the order in which the table arguments are parsed is essentially random.

The sketchybar api has some order-of-operation dependent properties, e.g:

sketchybar --set <name> background.color=0xffff0000 background.drawing=off`

Sets the background color — which enables the background automatically — and then disables the background again.
The same is not possible in lua (in a single set call) because:

<name>:set({ background = { color = 0xffff0000, drawing = false } })

Is not reliably parsed in this order. If this is parsed the other way around, the background is disabled and only then the color is set — which then enables the background automatically.

A fix for this will likely need to be on the sketchybar syntax side. I.e. all the sketchybar config options must be entirely independent of each other such that order of operations is never a problem.

[Marc-AnthonyG]

I had this problem while doing configuration for hovering element. What would be the best way around this issues as of right now. Declaring the colors and the drawing in two different set command? This might impact performance for event that are trigger a lot.

Could we hard code a fix in SbarLua for now?