Updating state from eruption-process-monitor

[Phen-Ro]

Thank you for allowing me to ransack your codebase while I look around to achieve a certain goal of mine.

Here's my "user story": I use focus-follows-mouse window policy on my computer and have multiple monitors. I may have several windows up across these monitors, such as web browsers, a music player, code editors, etc. Sometimes I watch fullscreen YouTube videos with my wife, who despite all these years does not agree with my window focus policy. She will use the spacebar to pause the video when she makes some remark while we watch YouTube. However, if the mouse has previously been nudged over to the music player, spacebar will instead unpause the music, resulting in ruinous cacophony. I use eruption-process-monitor to change the keyboard colors as a clear visual indicator for which window has focus. This is great when the window decorations are not apparent (e.g., due to the fullscreen video). When a YouTube window has focus, certain keys illuminate turn YouTube logo red. When Spotify has focus, the lights turn that uncomfortable shade of green of Spotify's logo. Harmony restored.

I have written custom scripts with a base profile for the keyboard colors, then copied the profile with different parameters for each window rule I want to handle. eruption-process-monitor requires a different profile for each rule, but what I want is 1) for the rules to switch profile parameters/states, not full profiles, and without having to tear down and re-initialize the scripts. And what I want even more is 2) for eruption-process-monitor to be able to pass some sort of information into the script as a parameter about the rule or window change. Ultimately, 3) it would be awesome if I had a single profile with a script that is notified when window change occurs, be given some window information that it can then use to ask the window manager for its icon, then generate a color palette based on that icon.

I think 3 isn't immediately doable, but it is possible, and would be cool. I think 2 is possible by adding some d-bus methods that eruption-process-monitor can call to pass the rule and/or window information, and then eruption can react to the d-bus message by invoking optional script callback functions in the same way that SetParameter works. It's not obvious what that window information should be. I haven't looked into what it would take to ask the window manager for icon info, but I would assume/hope there's some XDG way of doing that. And rather than doing that directly in Lua, perhaps a function could be exposed that can grab relevant window information. Maybe there can be a window_rule_change or window_focus_change callback, and a get_window_information() function exposed from the support library or something. It would take some thinking to design this right.

As for 1, I think this can be achieved soon, depending on how many free weekends I have. This would also require a new d-bus method. Maybe something like SwitchProfileWithState? Like SwitchProfile, it would take the profile filepath, but also take a state filepath. If the given profile does not match the active profile, the profile is first switched. Either way, the state would be deserialized and the parameters injected into the Lua VMs similar to SetParameter. One tricky part of this is that we want to update many parameters at once. SetParameter is set up to change one parameter at a time, and calling on_apply_parameter in Lua for every parameter change seems like not the way to go. Instead, we want to change all the parameters, then let the Lua script know that multiple parameters were changed at once. Rather than a name and a value, maybe on_apply_parameter should be a Lua table instead? Or maybe there should be a new callback, like on_apply_state? What would the implementations of these callbacks look like? I imagine in most all cases, they'd just re-run the initial setup performed in on_apply_parameter. If that's the case, then differentiating the two callbacks isn't useful. On the other hand, I would like to know which parameters have indeed changed from the script's perspective. And overall, I'd like to avoid rebuilding all the Lua VMs each time the state changes, especially if I want to change state every time my mouse moves across the screen.

What are your thoughts on these goals? Do any of them overlap or contradict with anything you already have in mind?

If you have no objection, then I think the first step would be to create that SwitchProfileWithState dbus interface and then either create a new Lua callback or change how on_apply_parameter works. Since on_apply_parameter was only recently supported, it would be a safe time to change its meaning.

[X3n0m0rph59]

Hi @Phen-Ro, great posting! This sounds really cool to me!

What are your thoughts on these goals? Do any of them overlap or contradict with anything you already have in mind?

They perfectly align to my vision of the project, so no contradictions at all! :-)

I would like to advance the project in a direction, where at some point in time it would be possible for the eruption-process-monitor daemon to introspect the memory of processes using predefined rules, or at the very least do some OCR/Pixel checking of the screen.
It would then be possible to reflect the internal state of, lets say a game (character alive/dead?; ammo count, etc..), via the LED lighting.

So we definitely need a way to efficiently convey structured data to the eruption daemon.

Btw. did you already have a look at the Eruption SDK? Support for Rust and Python should already be good enough to implement something as a standalone application. Eruption SDK-based applications talk to the eruption daemon over a UNIX domain socket (using Protocol Buffers), as opposed to a slower D-Bus based RPC protocol. So the SDK could be of interest as well...

If you have no objection, then I think the first step would be to create that SwitchProfileWithState dbus interface and then either create a new Lua callback or change how on_apply_parameter works. Since on_apply_parameter was only recently supported, it would be a safe time to change its meaning.

Yes, that sounds very reasonable!

[Phen-Ro]

I initially only glanced at the SDK briefly, but upon a second look, the python bindings would make it straightforward to throw together something that watches KWin-specific events and extracts icon data. A few minutes research suggested that a DE-agnostic way of achieving that may not be possible, but a python script specific to KWin feels appropriate. I'll dig into that more later.

Structured IPC data is always a challenging problem, but I've never thought to use protobufs over unix sockets. Is that common? Certainly an interesting idea. I wonder if it's reasonable to shove json-serialized messages through d-bus for desktop widgets. I've had half a mind to write a plasma widget similar to the gnome shell extension, but, one thing at a time.

Plundering the memory space of a game to extract player stats is totally insane but I'd love to see what you make of it. :)

Thanks for the response. Probably the next PR I make will refactor script.rs a bit and add a new Message::SetParameters function.