11:02 <ifreund> pushed some naming tweaks and documentation improvements to the river-xkb-keybinds-v1 draft

12:49 <ThatGuestAgain> ifreund You still have "default state" on line 99, and I still have questions :)

12:49 <ThatGuestAgain> If the modifiers for release are checked on press, what about the mode/state? Is the one from the press or release time used?

13:10 <ifreund> thanks for the line 99 catch

13:12 <ifreund> I think what we should do is specify that on key press bindings that have their trigger set to press or repeat are check first and if a match is found can trigger a state transition

13:13 <ifreund> then after that possible trigger and state transition the modifiers for release bindings are checked

13:14 <ifreund> Though that begs the question: "what if some other key press triggers another state transition before the key is released, and transitions into a state where there is no release keybind defined"

13:15 <ifreund> pehaps a better model is that we make note of the modifiers that were held on key press and use those saved modifiers to check the binding on release

13:16 <ifreund> and always check against the current mode

13:16 <ifreund> I think I like that approach most

13:17 <ThatGuestAgain> Maybe I should make an example of why I am asking in the first place. Lets say I have two physical special function keys I never use, foo and bar. I want each to enter a mode on press and leave it on release. There is also a combined mode foobar.

13:17 <ThatGuestAgain> Now pressing foo, pressing bar and releasing foo should get me through the states init->foo->foobar->bar. I wonder if that will be possible, or (due to early-checking) not.

13:19 <ifreund> yes, that should be possible if you define a release keybind for foo in the foobar state that transitions to the bar state

13:20 <ifreund> (with my proposed model of saving the mods that were held at press but checking for a keybind in the current state on release)

13:21 <ifreund> and it would work even if foo and bar were instead Super foo and Super bar and you released super before releasing foo

13:22 <ThatGuestAgain> Great! (I'd make the combination modes automatically from the user configured base ones in the wm of course).

13:22 <ifreund> yeah, makes sense :)

13:45 <ifreund> ThatGuestAgain: pushed another change to the protocol spelling this out explicitly and adding an example :)

16:32 <The_Buhs> Re the issue about idle inhibit and Firefox and whatever: Why does the idle inhibit protocol require a surface anyways? Like what if I just wanted to temporarily inhibit it without a specific surface being the cause?

16:33 <The_Buhs> Like I know that's not a river-specific thing, just wondering if anyone here knows lol

18:26 <ifreund> the protocol is only intended to deal with visual content and dimming/turning off displays

19:21 <The_Buhs> Makes sense, I guess. I guess I didn't think about the fact that like, you could want your computer to lock but still have music playing (or something like that).