Input/output of Keymapper virtual modifier state

[ristomatti]

In order to correct my bad judgement of starting an off-topic discussion on issue #102, The start of the discussion below, I'll reply on a new message.

@ristomatti commented:

This is a "nice to have" kind of thing and I'm not sure if Keymapper should support this. Hence, no feature request so far. Features I'd love to see more than this:

• a way to read/monitor virtual modifier state outside of Keymapper, perhaps also trigger key press/release events for them as well (related to the next one)
• a way to access to external data that could be used within mappings
• support for consecutive context blocks to use the same mappings (e.g. I'd like specific mappings to be available to some applications I can match using title, some only by using class context
• support for importing config blocks, in order to customize mappings to a specific app without unrelated configs distracting. I've looked into some template based file builders as a workaround

I don't wish to flood with feature requests though, just throwing them out in case they'd spark interest in @houmain. 😬

@houmain commented:

Thank you for the feature requests! They all sound good. I think the discussions area would have been the right place for this list. Maybe you could create a topic there.

• I think I could make the virtual modifier state accessible using DBUS.
• Which external data are you thinking of? Arguments for shell commands?
• I have already thought about the third point.

[ristomatti]

Agree. This was just an impulse reaction to an email notification from watching the repository.

I think I could make the virtual modifier state accessible using DBUS.

With my little knowledge of DBus, it sounds like a sensible approach. To be honestly though, I just learned about what DBus is for after I started using DBus desktop notifications as a tool to debug my config. What followed was an ugly hack of piping and grepping dbus-monitor in order to have the debug output (created by sprinkling command executions to run before text output) visible on the i3 status bar*.

An event based system would definitely be better than having to poll the values. For this to work (for my specific use case), it would be important for key release events to be sent out after a restart triggered by a config change.

I could come up with use cases where it would be useful to be able to read the current state on demand without having to maintain it externally on a separate monitoring process.

Monitoring and parsing the DBus events did seem somewhat "involved" for basic use cases though. After some searching, I came up with this list of existing tools that could potentially be useful for e.g. triggering shell scripts on events.

• alfmep/dbus-tool: dbus-tool is a multipurpose command line utility for the DBus interprocess communication system.
• erickloeckner/dbus-notifyd: A Linux daemon which listens for desktop notifications on DBus and triggers a Bash script.
• h3ndrk/dbus-notifications: Output desktop notifications on the command line in JSON format.\
• atotto/notify-record: Linux desktop notification recorder

Do you have an equivalent system in mind to make this available on Mac and Windows, given the cross platform support? Personally I would not mind only Linux support though.

Which external data are you thinking of? Arguments for shell commands?

Not exactly. I was thinking it would allow some potentially interesting use cases if there would be an additional context modifier for varying keyboard mappings depending on an external state other than device or the currently focused app. But without a specific use case in mind, better keep things simple. The ability to toggle virtual modifier state would likely suffice.

*) This sounds absurdly complicated means of doing this. I could have just just echo the stuff to a log file and tail if for the output. I was thinking of other use cases for this outside of debugging. Partly I blame lack of enough sleep.

[ristomatti]

@houmain Earlier this week I got an idea that'd be much cleaner if there would be a way to inject stateful information into the running Keymapper instance in one way or another. I've found myself going back and forth with Nordic and US layouts. There's a few annoying differences between the layouts (e.g. 1 key offset to get symbols ()). I'd like to create some mappings to alleviate the issue but to do that, I'd need to know the active layout.

I could probably work around this one by always switching the layout through Keymapper and toggling a virtual mod at the same time. I'd rather not do it in this way in case you're planning to add support for something that'd make it possible in a cleaner way.

[houmain]

Hi, I am thinking about making it possible to set/unset/toggle virtual keys by passing them to a new keymapper instance.
So it should be possible to call keymapper --set Virtual1 --unset Virtual2 to change their state. It should even be allowed to use aliases instead of VirtualN.

[ristomatti]

With the existing instance still running? Supporting aliases would be perfect. Could a separate executable make sense or would it be more work? For instance i3wm has i3-msg for command line interfacing with the running instance.

For me it doesn't matter but it sounds potentially confusing to reuse the same command that's intended to run in the background. Alternatively a sub command would suffice to clarify the difference e.g keymapper state --set/unset.

This is again just throwing in ideas but a --get Virtual1 would make a nice addition to this if it would not be too much additional work. This could return simply 0 or 1.

[houmain]

Yeah, a separate keymapper-msg would likely be better and not a whole lot more work.
And yes, a --get would be a nice addition which I will also try to implement. 👍

[ristomatti]

With the introduction of keymapperctl, I consider discussion closed. 🚀