xmonad / xmonad-contrib

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

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

Open liskin opened 5 months ago

liskin commented 5 months 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 4 months ago

Anyone happens to have an opinion about the API?

slotThe commented 4 months 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 4 months 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 4 months 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.