Logs: freenode/#xmonad
| 2021-05-12 16:44:21 | <dminuoso> | Sure, lets just stuck to that example - its fine |
| 2021-05-12 16:44:23 | <geekosaur> | so I can verify it sees the expected key |
| 2021-05-12 16:44:42 | <geekosaur> | emacs doesn't do key grabs, xmonad does |
| 2021-05-12 16:44:55 | <dminuoso> | How can I make emacs tell me this? It'd be nice if I could experiment myself |
| 2021-05-12 16:45:19 | <geekosaur> | it just reports it in the messages buffer "s-s is undefined" for mod-s with mod = mod4 |
| 2021-05-12 16:45:27 | <dminuoso> | Oh, I guess xev would suffice too |
| 2021-05-12 16:45:35 | <geekosaur> | the first "s" stands for "super", thanks MIT |
| 2021-05-12 16:45:39 | <geekosaur> | yeh |
| 2021-05-12 16:46:58 | <geekosaur> | xev's a little annoying since you need to position the mouse pointer in the box to see the key events on the terminal, then use a layout that lets them run side by side (but I most commonly use tabbed…) |
| 2021-05-12 16:47:37 | <dminuoso> | Well, since I only care about keyboard right now, the focus is not an issue. |
| 2021-05-12 16:48:08 | → | dariof4 joins (~dario@178.249.202.150) |
| 2021-05-12 16:49:25 | <dminuoso> | So this is interesting, if I start to press mod, keep it held, and then press a key say 'f' for which a passive grab exists in my xmonad, and then release 'f', and then release 'mod', xev does not receive a KeyRelease event for 'mod' |
| 2021-05-12 16:49:34 | <dminuoso> | How comes? |
| 2021-05-12 16:49:47 | <dminuoso> | Is the grab held until the entire key combination is released? |
| 2021-05-12 16:49:55 | <dminuoso> | (for a grab on key + modifier I mean) |
| 2021-05-12 16:50:35 | <geekosaur> | the passive grab is on the key release, I think, after wich all key events are directed to the grabbing client (xmonad, here) |
| 2021-05-12 16:50:51 | <dminuoso> | right, but key release of the entire modifier combination right? |
| 2021-05-12 16:50:57 | <geekosaur> | so neither xev nor anything else can see key events until xmonad drops the now-active grab |
| 2021-05-12 16:51:19 | <geekosaur> | generally not, just the "normal" key and not the modifier |
| 2021-05-12 16:51:40 | <geekosaur> | this leads to odd behavior if you bind a key both as a modifier and as a normal key |
| 2021-05-12 16:52:32 | <dminuoso> | wouldnt that suggest I should see a KeyRelease event for Super_L in the above scenario? |
| 2021-05-12 16:53:01 | <geekosaur> | no, because the grab becomes active at the key release for 'f' |
| 2021-05-12 16:53:23 | <geekosaur> | hm, I think that means it shouldn't see that one either |
| 2021-05-12 16:53:40 | <dminuoso> | hold on, the documentation suggests the grab becomes active at the key press |
| 2021-05-12 16:53:57 | geekosaur | is poking locally |
| 2021-05-12 16:54:28 | <dminuoso> | https://www.x.org/wiki/Development/Documentation/GrabProcessing/ |
| 2021-05-12 16:54:38 | <dminuoso> | "A client can create multiple passive grabs (GrabButton/GrabKey), and they become active whenever the specified button/key is pressed, until it is released again." |
| 2021-05-12 16:55:01 | <geekosaur> | fwiw I see all key presses and releases locally and I think I have mod-f bound |
| 2021-05-12 16:55:33 | <dminuoso> | Plus, if I read the bit about implicit passive grabs, that strengthens my position |
| 2021-05-12 16:55:42 | <dminuoso> | "[About implicit passive grabs:] The purpose of the grab is to ensure that a ButtonRelease event is delivered to the same client as the ButtonPress event." |
| 2021-05-12 16:56:02 | <dminuoso> | That wouldn't make any sense if the grab was activated on the release event |
| 2021-05-12 16:56:42 | geekosaur | apparentrly misremembered |
| 2021-05-12 16:58:44 | <dminuoso> | Mind my asking, how do you make emacs report unbound keys? |
| 2021-05-12 16:59:47 | <geekosaur> | it does it by default down in the message line |
| 2021-05-12 17:00:16 | <dminuoso> | Haha, years with emacs and I never noticed |
| 2021-05-12 17:00:20 | <geekosaur> | oh, my config didn't have mod-f bound after all |
| 2021-05-12 17:00:36 | <geekosaur> | it's getting passed through, I would have had to use something like mod-t that I do bind |
| 2021-05-12 17:02:04 | <dminuoso> | I think I have some experimentation to do. |
| 2021-05-12 17:02:47 | × | gzj quits (~gzj@unaffiliated/gzj) (Remote host closed the connection) |
| 2021-05-12 17:03:28 | <geekosaur> | so for what it's worth, with mod-t which I know my config binds, xev sees the modifier key press and release but neither one for the t |
| 2021-05-12 17:05:40 | <dminuoso> | Really? I find that interesting |
| 2021-05-12 17:05:48 | <dminuoso> | Oh, I have a theory of why.. |
| 2021-05-12 17:06:04 | <geekosaur> | you quoted it earlier |
| 2021-05-12 17:06:20 | <geekosaur> | >> "[About implicit passive grabs:] The purpose of the grab is to ensure that a ButtonRelease event is delivered to the same client as the ButtonPress event." |
| 2021-05-12 17:06:27 | <dminuoso> | No I meant, why I saw a different result in my xev than what you described |
| 2021-05-12 17:06:40 | <geekosaur> | oh |
| 2021-05-12 17:06:42 | <dminuoso> | Nope, still dont see a release event for mod key |
| 2021-05-12 17:07:15 | <geekosaur> | I had some WM_STATE and _NET_WM_STATE property change events before the key release |
| 2021-05-12 17:08:23 | <dminuoso> | Okay. my key combo created a new window, that seems like it influenced it |
| 2021-05-12 17:08:41 | <dminuoso> | I made a new key combo which just does `pure ()` as the action, and now I see the release event for Super_L |
| 2021-05-12 17:09:57 | <dminuoso> | and in fact, I see the grab notify on key down of f, and ungrab notify on release of f |
| 2021-05-12 17:10:39 | <dminuoso> | And as expected, no release event on t, since that would be sent to xmonad - as documented and expected |
| 2021-05-12 17:10:47 | <dminuoso> | (err, well f rather than t) |
| 2021-05-12 17:14:11 | × | pmj quits (~pmj@ipbcc2919d.dynamic.kabel-deutschland.de) (Ping timeout: 240 seconds) |
| 2021-05-12 17:17:52 | <dminuoso> | Time to glue xmonad to dbus. :) |
| 2021-05-12 17:18:04 | <dminuoso> | I sense great things on the horizon |
| 2021-05-12 17:18:38 | <geekosaur> | you'll need to rework the main loop, which currently assumes sleeping on XNextEvent() is sufficient |
| 2021-05-12 17:19:28 | <dminuoso> | oh |
| 2021-05-12 17:19:49 | <dminuoso> | I think I can work with that, does xmonad allow for hooks into the main l,oop? |
| 2021-05-12 17:22:50 | <geekosaur> | not currently |
| 2021-05-12 17:23:46 | <geekosaur> | I've thought about reworking it to listen for fd events (then you could hook in whatever) and passing the additional events to handleEventHook somehow, but it'd require extending it to support more than X11 events |
| 2021-05-12 17:23:58 | <geekosaur> | otr making generic fd hooks look like clientMessage events |
| 2021-05-12 17:28:52 | <dminuoso> | So my endgoal is to keep a keyboard led synchronized with the mute state of my microphone.. since I dont want to set up a separate server, I figured why not plug this into my xmonad. |
| 2021-05-12 17:29:08 | <dminuoso> | just subscribe to the respective dbus events (and perhaps send some back to manipulate the mute state) |
| 2021-05-12 17:34:22 | <geekosaur> | tbh we usually recommend doing that kind of thing outside of xmonad, to keep it small and focused |
| 2021-05-12 17:37:08 | <dminuoso> | And here I was, playing with the joke of writing xmonacs - a window manager with full emacs power builtin. |
| 2021-05-12 17:37:48 | <dminuoso> | Humor aside, Im just experimenting with various ideas here. |
| 2021-05-12 17:44:10 | × | abhixec quits (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Read error: Connection reset by peer) |
| 2021-05-12 17:48:22 | <Solid> | that would probably by exwm ;) |
| 2021-05-12 17:53:43 | <geekosaur> | someone iirc actually wrote a major mode for emacs that made it a window manager. it didnt go well, mostly because emacs is single-threaded and can't do things like window management and user interaction at the same time |
| 2021-05-12 17:57:22 | <ElKowar[m]> | Pretty sure there are a good few people that actually do use EXWM as their daily driver - they just learned to not do the things that block the main thread, and learned to deal with it |
| 2021-05-12 18:05:00 | <dminuoso> | Unrelatedly, I have a Cal key on my keyboard, which xev reports as XF86Calculator - how can I provide a keybinding for that? |
| 2021-05-12 18:05:14 | <dminuoso> | state 0x0, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES, |
| 2021-05-12 18:05:34 | × | notis quits (~notis@85.203.44.149) (Ping timeout: 252 seconds) |
| 2021-05-12 18:06:42 | <dminuoso> | Do I have to modmap 148 to say Hyper_L and use that? |
| 2021-05-12 18:06:50 | <geekosaur> | use the hex keysym, not the keycode |
| 2021-05-12 18:07:09 | <dminuoso> | Oh, KeySym is just integral, did not realize |
| 2021-05-12 18:07:15 | <geekosaur> | you don't have to map it to a modifier, unless you intend to use it as one (that is, like a shift or control key) |
| 2021-05-12 18:07:31 | <dminuoso> | No, I want it as its own kney |
| 2021-05-12 18:07:35 | <geekosaur> | unwrap all the newtypes and type aliases and it's just CInt, iirc |
| 2021-05-12 18:08:05 | <geekosaur> | hm, no newtypes, just a 6-deep nest of aliases :) |
| 2021-05-12 18:10:44 | <Liskni_si> | geekosaur: http://haskell.org/haskellwiki/Image:Xmbindings.png works again |
| 2021-05-12 18:10:59 | <geekosaur> | yay |
| 2021-05-12 18:11:44 | <Liskni_si> | > these are redirects from old urls that were put in place when we migrated the wiki to a new domain years ago, and got lost when we just migrated the server. |
| 2021-05-12 18:11:45 | <lambdabot> | <hint>:1:49: error: <hint>:1:49: error: parse error on input ‘in’ |
| 2021-05-12 18:11:50 | <Liskni_si> | > (davean had temporarily disabled the rewrite rule in order to see if he could improve it, but it never got reenabled or improved -- so for now i just turned it back on) |
| 2021-05-12 18:11:52 | <lambdabot> | <hint>:1:51: error: <hint>:1:51: error: parse error on input ‘in’ |
| 2021-05-12 18:12:30 | <dminuoso> | geekosaur: mmm, 148 does not appear to be working. |
| 2021-05-12 18:12:43 | <geekosaur> | use the hex keysym, not the keycode |
| 2021-05-12 18:13:09 | <geekosaur> | xmonad translates keysyms to keycodes internally and does not expose keycodes directly |
| 2021-05-12 18:13:15 | <dminuoso> | ahh |
| 2021-05-12 18:13:44 | <dminuoso> | this works beautifully, thanks |
| 2021-05-12 18:29:47 | → | pmj joins (~pmj@ipbcc2919d.dynamic.kabel-deutschland.de) |
| 2021-05-12 18:40:06 | × | geekosaur quits (930099da@rrcs-147-0-153-218.central.biz.rr.com) (Quit: Connection closed) |
| 2021-05-12 18:40:28 | → | geekosaur joins (930099da@rrcs-147-0-153-218.central.biz.rr.com) |
| 2021-05-12 18:42:21 | → | ElKowar joins (~ElKowar@srv-fin.xware-gmbh.de) |
| 2021-05-12 18:46:36 | → | kr1x joins (~kriket@2607:fb90:d240:a660:6135:38f4:620a:b2e) |
| 2021-05-12 18:46:38 | × | kr1x quits (~kriket@2607:fb90:d240:a660:6135:38f4:620a:b2e) (Client Quit) |
| 2021-05-12 18:48:18 | × | electr0n quits (~electr0n@about/security/founder/electr0n) (Quit: WeeChat 3.1) |
| 2021-05-12 18:50:54 | × | ElKowar quits (~ElKowar@srv-fin.xware-gmbh.de) (Quit: The Lounge - https://thelounge.chat) |
All times are in UTC.