xmonad / xmonad-contrib

Contributed modules for xmonad
https://xmonad.org
BSD 3-Clause "New" or "Revised" License
579 stars 271 forks source link

X.A.Repeatable: Auto-detect modifier keys from currentEvent #892

Open liskin opened 1 month ago

liskin commented 1 month ago

Description

This makes all the cycleSomething key bindings easier to use: users don't need to manually list the KeySyms of modifier keys in addition to specifying the mask for the keybinding itself. We can easily get those KeySyms from the KeyEvent currently being handled with the help of XGetModifierMapping.

This only implements the logic in X.A.Repeatable. We need to decide whether to change the API of all the user-facing functions (drop the mods argument), just document that empty list means "auto-detect", or some combination thereof.

Checklist

liskin commented 1 day ago

Anyone happens to have an opinion about the API?

slotThe commented 1 day ago

This sounds much better than the current situation, but I guess breaking user configs by dropping an argument is always a bit "eh" :/

geekosaur commented 17 hours ago

New API and mark the old one as deprecated? Or just go with "empty list means get it from the event"? Also, do we want to think about this for https://hackage.haskell.org/package/xmonad-contrib-0.18.0/docs/XMonad-Actions-CycleWindows.html#v:cycleRecentWindows?

liskin commented 11 hours ago

Also, do we want to think about this for https://hackage.haskell.org/package/xmonad-contrib-0.18.0/docs/XMonad-Actions-CycleWindows.html#v:cycleRecentWindows?

X.A.Repeatable is used in X.A.CycleWindows, and also in X.A.{CycleWorkspaceByScreen,CycleRecentWS,MostRecentlyUsed} so changing the API would result in quite a lot of breaking changes, or at least quite a lot of new function names and lot of deprecations.

I guess going with the "empty list …" option is better then. Or something.