Python-based rule handling

[lenrik1589]

Information

• Solaar version: 1.1.13-1 from arch extra/solaar (feature parity w/ master @ the time of the request filing)
• Distribution: Arch
• Kernel version: Linux 6.8.9-arch1-2 x86_64
• Output of solaar show: N/A

Feature request It would be really nice to have an option to be able to manually write a python (as i understand solaar is an entirely python program?) snippet or function that could take a hid++ notification, and execute appropriate actions

Additional context I've seen several requests that are either directly about storing extra state information somewhere, having an ability to write a python notification handler instead of a yaml tree, would allow much easily store state (for example just giving the user a state dict in the context of a handler would solve that

[pfps]

One problem is how to do this. Python eval() only evaluates expressions.

[lenrik1589]

There is also exec() that does the whole code block

[pfps]

Yes, that would be better.

[MattHag]

This can be done as dynamically loaded plugin, but all of them have security implications and potentially introduce a security issue.

[pfps]

Using exec and eval might be safer. If this is allowed, Solaar should check to see that the rules file has reasonable permissions.

[pfps]

The idea would be to allow snippets of Python code in rules and exec or eval them. The rules file would have to be owned by the user and not be writable by anyone else.

Comments?

[MattHag]

Refactor the existing code to act like plugins that can handle HIDPP notifications.

And then it could be possible to support dynamically loaded plugins given in a specific path. Don't introduce an unmaintaintainable nightmare, when people fail to use the basics, die to unintuitive UI.

[lenrik1589]

all of them have security implications and potentially introduce a security issue.

There's a literal "run command" rule, which allows user to run any command they could wish to.

Technically all the "run python snippet" things can be done with python -c but requires writing code in a much more awkward way, and likely editing the the rules.yaml by hand because of how awkward the rule editor ui is (at least in the latest release) (or it requires python query-all-solaar-state-and-figure-out-what-to-do.py).

Storing variables would have to be delegated to a seperate temporary file, or all of that could be done with IPC (with a seperate app running alongside solaar just to get HIDPP notifs redirected from solaar), but i think we can agree that that would be more annoying than just having a python app run python code (and having an extra app would imo kinda defeat the purpose of having solaar in the first place, idk).

Plus handling of gestures is still performed on release, which is the opposite of one of the features of official app that i like: when a mouse gesture is set to change volume/brightness/w/e it'll do it in a continuous manner, unlike solaar, where gestures are performed in discrete steps which completely breaks the feeling, and so right now the i have resorted to having diverted forward button+scroll as volume control (but even w/ scroll i have issues where i have no clue how to detect whether the wheel is in free spin state or in stepped scrolling mode, to select what kind of scroll i want to execute) but having a python script handle all the processing would allow defining custom handling for all of the above.

If doing a refactor of rule handler to act more like a default plugin, "rule editor" could bring up a relevant editor, be it built-in yaml editor, or system text editor, as it can be defined per-plugin, and used plugin could be selected w/ a dropdown adjacent to rule editor button in the main menu, if that makes sense?

Having rules.py or rules.yaml (maybe even config.yaml/json) be 0600 or 0644 makes sense to me.