Logs: liberachat/#xmonad
| 2021-12-17 18:07:03 | → | ml| joins (~ml|@user/ml/x-5298235) |
| 2021-12-17 19:09:07 | → | Vermoot joins (~vermoot@89-158-106-112.rev.numericable.fr) |
| 2021-12-17 19:13:08 | → | electr0n joins (~electr0n@about/security/founder/electr0n) |
| 2021-12-17 19:28:30 | → | abhixec joins (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) |
| 2021-12-17 19:34:44 | → | abhixec[m] joins (~abhixecma@2001:470:69fc:105::a2a) |
| 2021-12-17 19:35:51 | <abhixec> | geekosaur: even though I kind of managed to fix that issue on google chrome code and other electron based apps still hang/show blank context menus |
| 2021-12-17 19:38:00 | <geekosaur> | if toggling hardware acceleration fixed it in chrome, there's a decent chance it's a driver issue. can't really be an xmonad issue as client rendering is completely between the x server and the client; the window manager only controls window position / sizing, not drawing |
| 2021-12-17 19:38:16 | ← | abhixec[m] parts (~abhixecma@2001:470:69fc:105::a2a) () |
| 2021-12-17 19:38:58 | <abhixec> | geekosaur: thanks let me see if I dig something on this on archwiki |
| 2021-12-17 19:42:48 | <geekosaur> | (the only desktop component that is involved with drawing is the compositor, which is why my earlier suggestion. plus we've actually seen that one happen) |
| 2021-12-17 19:45:27 | <abhixec> | the strange thing is everything seems to work fine on laptop just when I connect to external monitor I see this issue |
| 2021-12-17 19:48:33 | <geekosaur> | that also suggests the driver, sadly |
| 2021-12-17 19:48:43 | <geekosaur> | because it's about the only thing that can see a difference |
| 2021-12-17 19:49:51 | <abhixec> | *facepalm* nvidia!!! |
| 2021-12-17 19:54:54 | × | abhixec quits (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Quit: rebooting) |
| 2021-12-17 19:55:36 | → | twiclo joins (~twiclo@2604:7b80:2000:1069:52fc:cedd:fbeb:10c) |
| 2021-12-17 19:56:50 | <twiclo> | Does anyone know of a way to select a workspace when you mouse over it? If you have an empty desktop you have to click it before you can spawn things to i twith dmenu |
| 2021-12-17 20:01:01 | → | abhixec joins (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) |
| 2021-12-17 20:01:02 | × | twiclo quits (~twiclo@2604:7b80:2000:1069:52fc:cedd:fbeb:10c) (Ping timeout: 240 seconds) |
| 2021-12-17 20:03:28 | <FOSSHuman[m]> | <twiclo> "Does anyone know of a way to..." <- I use XMobar which doesn't have a feature to do this I dont think |
| 2021-12-17 20:04:02 | <FOSSHuman[m]> | I think some other bars like Taffybar might? be able to do this though |
| 2021-12-17 20:04:27 | <FOSSHuman[m]> | * like Taffybar (might?, * might?) be |
| 2021-12-17 20:05:00 | <geekosaur> | bars generally can't do this (mouseover, not click) |
| 2021-12-17 20:05:13 | <FOSSHuman[m]> | <twiclo> "Does anyone know of a way to..." <- Or you can just spawn something with dmenu and then shift it to the workspace or use a manageHook |
| 2021-12-17 20:05:15 | <geekosaur> | xmonad might be able to do it with a handleEventHook |
| 2021-12-17 20:06:16 | <geekosaur> | with some shortcomings, for example desktop windows are pretty much impossible to handle that way |
| 2021-12-17 20:06:36 | <kwer[m]> | This came up recently in the xmonad subreddit: https://www.reddit.com/r/xmonad/comments/qi1tlm/focus_empty_workspace_on_cursor_hover/ |
| 2021-12-17 20:07:32 | <FOSSHuman[m]> | kwer[m]: "Yeah, I also experience this occassionally (not always, seems to depend on the speed of pointer movement). This is definitely not a configuration issue, but a bug in xmonad core." |
| 2021-12-17 20:07:35 | <FOSSHuman[m]> | is what Liskin said |
| 2021-12-17 20:08:12 | <FOSSHuman[m]> | Actually, I was wondering why this was happening too when I had two monitors running |
| 2021-12-17 20:11:16 | <FOSSHuman[m]> | @kwer: thanks for posting that link btw, I rarely check XMonad Reddit |
| 2021-12-17 20:11:17 | <lambdabot> | Unknown command, try @list |
| 2021-12-17 20:11:44 | <geekosaur> | oh, now I see where xmobar came into it. that wouldn't be xmonad core but something about the X server compressing out extra motions it thinks aren't necessary :( |
| 2021-12-17 20:12:17 | <geekosaur> | would need the xmobar to be an InputOnly window to change that, I think? |
| 2021-12-17 20:14:59 | <kwer[m]> | FOSSHuman[m]: It's a shameless plug 😉 |
| 2021-12-17 20:15:40 | <geekosaur> | kwer[m], how would you feel about packaging up your little setup and submitting it to -contrib? |
| 2021-12-17 20:17:52 | <FOSSHuman[m]> | I thought X.A.UpdateFocus could fix this behaviour, but according to @geekosaur it is more internal |
| 2021-12-17 20:18:09 | <FOSSHuman[m]> | I guess it was just bcs of the name |
| 2021-12-17 20:19:04 | <FOSSHuman[m]> | It does say |
| 2021-12-17 20:19:20 | <FOSSHuman[m]> | * does say "Updates the focus on mouse move in unfocused windows." so its unrelated anyway I guess |
| 2021-12-17 20:20:41 | <kwer[m]> | geekosaur: Haha yeah, some other people suggested that as well. I'm not sure about the desktop focus because it does listen to all pointer movements. I was considering limiting it but it seems that the Haskell interface to Xlib doesn't report the time for pointer motion events |
| 2021-12-17 20:21:57 | <kwer[m]> | FOSSHuman[m]: Hmm, I guess it only listens to window entry events? Here, the issue is that you're in the root window the whole time |
| 2021-12-17 20:33:55 | <FOSSHuman[m]> | `alt + w/e/r` with X.A.UpdatePointer works pretty decently, it just moves to pointer to the other screen when pressing that keybind. Even though physically moving the mouse to the other screen sometimes doesn't switch XMonad to that workspace that the other screen is using (if no windows are present on the other screen)... |
| 2021-12-17 20:36:13 | <FOSSHuman[m]> | s/that/either/, s/keybind/of them keybinds/ |
| 2021-12-17 20:37:26 | <FOSSHuman[m]> | But clicking on the desktop on the other screen does move XMonad to the workspace that the other screen is using |
| 2021-12-17 20:38:16 | <FOSSHuman[m]> | * the desktop when no windows are present on the |
| 2021-12-17 20:48:02 | → | curiousgay joins (~curiousga@77-120-141-90.kha.volia.net) |
| 2021-12-17 20:50:23 | <kwer[m]> | Actually, what you said earlier, FOSS Human , might be better than listening to all pointer motion events. In the end, if the workspace is empty, what's the point of shifting the focus? One could just check where the pointer is whenever a new window is added and move it there. Would that be possible or would it force the wrongly focussed workspace to get rearranged before the window is moved? |
| 2021-12-17 20:51:18 | <geekosaur> | sounds like it'd be difficult or at least annoying if the manageHook shifts the window elsewhere |
| 2021-12-17 20:51:45 | <geekosaur> | obvious answer to that would be the logHook, except changing workspace or window focus would rerun it |
| 2021-12-17 20:55:17 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-12-17 20:55:48 | <kwer[m]> | But couldn't you handle MapRequestEvents in your custom logHook (which I think is run before the default one) and shift the focus if necessary? |
| 2021-12-17 20:58:45 | <geekosaur> | the default is empty, and if the user does chain to it they could do so anywhere |
| 2021-12-17 20:59:30 | <geekosaur> | if you're looking for events that's handleEventHook, but MapRequest would end up being done before the window was managed (and therefore before the manageHook) |
| 2021-12-17 21:39:17 | × | obimod quits (~obimod@gateway/vpn/pia/obimod) (Ping timeout: 240 seconds) |
| 2021-12-17 21:39:37 | → | obimod joins (~obimod@gateway/vpn/pia/obimod) |
| 2021-12-17 21:55:37 | → | mohab joins (~mohab@45.245.18.151) |
| 2021-12-17 21:58:30 | → | banc joins (banc@gateway/vpn/airvpn/banc) |
| 2021-12-17 22:46:33 | → | benin joins (~benin@183.82.27.121) |
| 2021-12-17 22:56:22 | × | mohab quits (~mohab@45.245.18.151) (Quit: WeeChat 3.3) |
| 2021-12-17 23:06:42 | → | twiclo joins (~twiclo@2604:7b80:2000:1069:52fc:cedd:fbeb:10c) |
| 2021-12-17 23:09:29 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3) |
| 2021-12-17 23:19:04 | <kwer[m]> | <geekosaur> "if you're looking for events..." <- Indeed, I meant handleEventHook. But so you could shift the focus when a MapRequest comes in before returning All True, which then runs the default handler that actually manages the window, right? Sorry for obsessing about this, it just seems like overkill to trigger on every pointer motion. |
| 2021-12-17 23:24:00 | <geekosaur> | as far as xmonad is concerned focus doesn't exist to be switched before the window is managed. that said, I'm not sure how this helps with pointer motion if the point is to focus a particular screen on hover? |
| 2021-12-17 23:25:42 | <twiclo> | I can't for the life of me figure out how to get desktop information into xmobar. Would someone be willing to show me their config and explain for me how you have that set up? |
| 2021-12-17 23:28:05 | <kwer[m]> | Right, as far as I understand, the issue only exists if the workspace on the second screen is empty; otherwise, as long as the pointer moves into window, that is focussed anyway (at least by default). But if the workspace is empty, it seems like the only artifact that people observe is that new windows open on the wrong workspace. So it would be enough to handle that case. Even though, as I'm typing this, I already realise that for example |
| 2021-12-17 23:28:05 | <kwer[m]> | scratchpads would be another issue and would appear on the wrong screen as well :/ |
| 2021-12-17 23:29:00 | <kwer[m]> | But I understand that it might be a lost cause, especially if you say so who knows the whole system a lot better. |
| 2021-12-17 23:30:22 | <geekosaur> | I think if we wanted to do this optimally, then with focusFollowsMouse we'd put InputOnly windows over all unfocused screens and switch monitor focus on CrossingEvent |
| 2021-12-17 23:31:39 | <geekosaur> | although, do you want simply crossing or hover? (I'd be annoyed by simple crossing, but then I don't use focusFollowsMouse anyway) |
| 2021-12-17 23:48:24 | × | ml| quits (~ml|@user/ml/x-5298235) (Quit: WeeChat 3.3) |
| 2021-12-18 00:00:29 | × | steve__ quits (~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 268 seconds) |
| 2021-12-18 00:09:57 | × | seschwar quits (~seschwar@user/seschwar) (Ping timeout: 256 seconds) |
| 2021-12-18 00:10:13 | × | obimod quits (~obimod@gateway/vpn/pia/obimod) (Remote host closed the connection) |
| 2021-12-18 00:10:32 | → | obimod joins (~obimod@gateway/vpn/pia/obimod) |
| 2021-12-18 00:12:30 | → | seschwar joins (~seschwar@user/seschwar) |
| 2021-12-18 00:19:07 | → | ml| joins (~ml|@user/ml/x-5298235) |
| 2021-12-18 00:31:01 | <kwer[m]> | <geekosaur> "I think if we wanted to do..." <- Yes, I was considering that and still want to make it work; especially since my original goal at some point was to restrict the cursor to a screen, which is not possible at the moment afaik. However, I'm afraid my X11-game isn't good enough for that (yet) |
| 2021-12-18 00:44:41 | → | mvk joins (~mvk@2607:fea8:5cdd:f000::745c) |
| 2021-12-18 00:50:42 | × | seschwar quits (~seschwar@user/seschwar) (Quit: :wq) |
| 2021-12-18 01:34:26 | × | gruntsplatter2 quits (~sogens@gateway/vpn/pia/sogens) (Quit: WeeChat 3.3) |
| 2021-12-18 02:16:53 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2021-12-18 02:18:27 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2021-12-18 02:49:45 | → | mohab joins (~mohab@156.223.125.34) |
| 2021-12-18 03:02:57 | × | banc quits (banc@gateway/vpn/airvpn/banc) (Ping timeout: 240 seconds) |
| 2021-12-18 03:08:37 | × | Vermoot quits (~vermoot@89-158-106-112.rev.numericable.fr) (Read error: Connection reset by peer) |
| 2021-12-18 03:08:48 | → | Vermoot joins (~vermoot@89-158-106-112.rev.numericable.fr) |
| 2021-12-18 03:16:13 | × | mohab quits (~mohab@156.223.125.34) (Quit: WeeChat 3.3) |
| 2021-12-18 03:22:02 | × | td_ quits (~td@94.134.91.242) (Ping timeout: 240 seconds) |
| 2021-12-18 03:23:58 | → | td_ joins (~td@94.134.91.199) |
| 2021-12-18 03:24:36 | → | banc joins (banc@gateway/vpn/airvpn/banc) |
| 2021-12-18 04:34:46 | × | curiousgay quits (~curiousga@77-120-141-90.kha.volia.net) (Quit: Leaving) |
| 2021-12-18 05:53:57 | × | obimod quits (~obimod@gateway/vpn/pia/obimod) (Ping timeout: 240 seconds) |
| 2021-12-18 06:08:19 | → | obimod joins (~obimod@gateway/vpn/pia/obimod) |
| 2021-12-18 07:05:57 | × | mvk quits (~mvk@2607:fea8:5cdd:f000::745c) (Ping timeout: 240 seconds) |
| 2021-12-18 07:31:16 | × | gdd1 quits (~gdd@129.199.146.230) (Ping timeout: 268 seconds) |
| 2021-12-18 08:18:51 | × | obimod quits (~obimod@gateway/vpn/pia/obimod) (Remote host closed the connection) |
| 2021-12-18 08:19:11 | → | obimod joins (~obimod@gateway/vpn/pia/obimod) |
| 2021-12-18 09:16:28 | × | ebray187 quits (~ebray187@2800:150:129:17c4:224:1dff:fed5:599e) (Quit: Konversation terminated!) |
| 2021-12-18 09:17:36 | → | allbery_b joins (~geekosaur@xmonad/geekosaur) |
All times are in UTC.