~mil/sxmo-tickets#524: 
rework multikey script in sway and way more

On sway I initialy implemented a shell script to have multikey actions with the three hardware buttons. This script brings issues like key stucked, bad performance, impossible to extends. Also, ideally a better solution would be used by both dwm and sway.

I'm currently thinking about this new solution and got multiple use cases in mind :

  • Replace sxmo hardware multikey action trigger
  • Replace the sxmo_hook_inputhandler.sh (trigger action depending on the sxmo contexts)
  • This solution would also be a good domotic core to trigger action on events depending on contexts. We should be able to use it for more than sxmo

I plan to write this solution as a client-server in hare lang. It will be also possible to use it over network.

From the sway side it would be as easy as :

bindsym --locked --input-device="$vol" XF86AudioRaiseVolume exec fooctl volup_pressed
bindsym --locked --released --input-device="$vol" XF86AudioRaiseVolume exec fooctl volup_released

("fooctl" cause I dont have name for this yet)

The daemon would be simply managed by superd.

Ideally the daemon would read a configuration file, command args but we should also be able to add or update the workflow tree with commands.

The daemon will follow configured workflows tree with nodes. There would be a current node that will change to the next available one when it match conditions.

Here some example for sxmo :

example context:

  locked: false
  mpc: playing
  focused_window: ncmpcpp
  has_notification: true

basic volup workflow example:

context(locked:false;)
  event(volup_pressed)
    delay(600)
      exec(sxmo_wmmenu.sh)
    event(volup_released)
      delay(300)
        exec(sxmo_appmenu.sh)
      event(volup_released)
        delay(300)
          exec(sxmo_appmenu.sh sys)
        event(volup_released)
          exec(sxmo_wmmenu.sh)

context nodes:

  • if we match all variables we go to childs

event nodes:

  • if we receive the event we go to childs

delay nodes:

  • if the time pass this delay without any event we go to childs

exec node:

  • exec the command and go to childs if succeed

no available child:

  • we reset the current node to default

As you notice, event name are arbitrary. In the example I used hardware pressed and release but here some other examples :

  • sms_arrived
  • call_arrived
  • locked
  • unlocked
  • window_focused
  • you tell me

As you can probably figure out it would be possible to have more complex workflows. By example :

  • to hold one button and clicking in another
  • to click on one button then another one

This project only exists theorically and in my mind (and here) for the moment. I'll learn harelang while developing this so it will take some time

I share this to have design feedback ! feels free to build a workflow tree that match your use cases to face it !

Status
REPORTED
Submitter
~stacyharper
Assigned to
No-one
Submitted
4 months ago
Updated
4 months ago
Labels
No labels applied.

~stacyharper 4 months ago

Arf I sent my wip workflow :D Here the workflow I edited in the ticket. Sorry dear email readers

context(locked:false;)
  event(volup_pressed)
    delay(600)
      exec(sxmo_wmmenu.sh)
    event(volup_released)
      delay(300)
        exec(sxmo_appmenu.sh)
      event(volup_released)
        delay(300)
          exec(sxmo_appmenu.sh sys)
        event(volup_released)
          exec(sxmo_wmmenu.sh)

~stacyharper 4 months ago

Register here or Log in to comment, or comment via email.