Logs: freenode/#xmonad
| 2020-12-04 09:00:30 | <mc47> | Hello! Is there a reason the test suite in xmonad-contrib is the way it is? Why not go with something similar to what there is in the core package? |
| 2020-12-04 09:07:15 | → | malook joins (~Thunderbi@5.108.42.152) |
| 2020-12-04 09:15:42 | × | malook quits (~Thunderbi@5.108.42.152) (Quit: malook) |
| 2020-12-04 09:20:23 | <Solid> | I was wondering the same thing at some point |
| 2020-12-04 09:21:05 | <Solid> | someone else apparently also did: https://github.com/xmonad/xmonad-contrib/issues/381 :P |
| 2020-12-04 09:21:31 | <mc47> | I saw that issue and thought "isn't it just stack test?" |
| 2020-12-04 09:21:35 | <mc47> | I was... wrong |
| 2020-12-04 09:21:41 | <Solid> | yeah exactly |
| 2020-12-04 09:21:48 | <Solid> | it's just `stack test` with the core repo |
| 2020-12-04 09:21:52 | <Solid> | but contrib does weird things |
| 2020-12-04 09:22:02 | <Solid> | I'd vote for unifying this so I can just `stack test` in contrib as well |
| 2020-12-04 09:22:19 | <Solid> | s/I can/one can/ |
| 2020-12-04 09:26:01 | <mc47> | I'd work on that in the weekend, after I clear my assignments |
| 2020-12-04 09:27:01 | <mc47> | it doesn't seem complicated: all the genMain script is doing is just generating a Properties.hs and a Main.hs file... I'll generate them, make them work, and remove genMain. We'd only need to make sure to sync these files whenever we add tests |
| 2020-12-04 09:27:09 | <mc47> | which is a good comrpomise, seeing what there is now |
| 2020-12-04 09:31:27 | × | mc47 quits (~yecinem@89.246.239.190) (Quit: Leaving) |
| 2020-12-04 09:36:09 | <Solid> | sounds good to me |
| 2020-12-04 09:37:09 | → | mc47 joins (~yecinem@89.246.239.190) |
| 2020-12-04 09:37:35 | × | mc47 quits (~yecinem@89.246.239.190) (Client Quit) |
| 2020-12-04 09:37:53 | → | mc47 joins (~yecinem@89.246.239.190) |
| 2020-12-04 09:45:03 | <coldpress> | dminuoso: oh, I thought you said it was a firefox problem. I had firefox flicker when running compton, and I believe setting layers.acceleration there solved my problem |
| 2020-12-04 09:46:04 | <dminuoso> | coldpress: It just exhibits when firefox is ontop, but I strongly believe it happens precisely when some slack control is behind. I dont fully understand how X11 works, but it seems almost as if when the mouse position is ontop of the slack control (which in the window stack is behind firefox) there's some "fighting" going on |
| 2020-12-04 09:46:35 | <dminuoso> | Where "slack" very shortly appears ontop, and then hides again. I dont have proof of this, but I managed to "fix" it by moving slack to a different screen. |
| 2020-12-04 09:47:24 | <Liskni_si> | coldpress, dminuoso: compton/picom flickers when use-damage is enabled, btw |
| 2020-12-04 09:47:31 | <dminuoso> | I dont have a compositor |
| 2020-12-04 09:47:36 | <Liskni_si> | Oh |
| 2020-12-04 09:59:17 | → | isgy joins (~jy@82.38.116.187) |
| 2020-12-04 10:03:51 | → | thc202 joins (~thc202@unaffiliated/thc202) |
| 2020-12-04 10:17:16 | × | plantations quits (~stalled@2001:ac8:92:a:0:1:73e:2265) (Remote host closed the connection) |
| 2020-12-04 10:18:58 | <Liskni_si> | seems I'm not the only one who thinks a process boundary between compositor and WM is a good idea: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/ |
| 2020-12-04 10:19:39 | <Liskni_si> | I didn't even know about this Arcan thing, which seems to be an alternative to Wayland |
| 2020-12-04 10:19:53 | <Liskni_si> | the world is messier than I thought :-) |
| 2020-12-04 10:20:20 | → | berberman_ joins (~berberman@unaffiliated/berberman) |
| 2020-12-04 10:20:26 | × | berberman quits (~berberman@unaffiliated/berberman) (Ping timeout: 264 seconds) |
| 2020-12-04 10:38:22 | → | malook joins (~Thunderbi@5.108.42.152) |
| 2020-12-04 10:45:03 | × | malook quits (~Thunderbi@5.108.42.152) (Quit: malook) |
| 2020-12-04 10:51:21 | × | tugrik quits (~username@war.funkyjesus.org) (Quit: WeeChat 2.9) |
| 2020-12-04 11:08:39 | × | mc47 quits (~yecinem@89.246.239.190) (Remote host closed the connection) |
| 2020-12-04 11:17:25 | × | ericsagnes quits (~ericsagne@2405:6580:0:5100:43fe:8354:1780:830b) (Ping timeout: 272 seconds) |
| 2020-12-04 11:29:16 | → | ericsagnes joins (~ericsagne@2405:6580:0:5100:2a4b:4c53:e4dc:e61e) |
| 2020-12-04 12:04:24 | × | Rockj quits (~rockj@2001:67c:550:feed::1) (Ping timeout: 240 seconds) |
| 2020-12-04 12:16:43 | → | Rockj joins (~rockj@2001:67c:550:feed::1) |
| 2020-12-04 12:28:35 | → | jchia__ joins (~jchia@58.32.37.146) |
| 2020-12-04 12:29:18 | → | tugrik joins (~username@war.funkyjesus.org) |
| 2020-12-04 13:16:17 | → | geekosaur joins (82659a09@host154-009.vpn.uakron.edu) |
| 2020-12-04 13:37:16 | → | sfrique joins (~sfrique@189.122.177.88) |
| 2020-12-04 13:39:20 | <vrs> | Hash: I once considered doing some sorcery with CRIU so that I could restore xmonad sessions across reboots, but then decided that this was a tarpit and didn't pursue it. The TopicSpaces way of having commands associated with workspaces is good though and I recommend it |
| 2020-12-04 13:40:29 | <vrs> | maybe it's just my config but I have it set up so that when I switch to certain named workspaces via gridselect and they're empty, they will be populated with the associated application |
| 2020-12-04 13:40:29 | <geekosaur> | a tarpit is definitely is |
| 2020-12-04 13:40:52 | <geekosaur> | that's how TopicSpaces works |
| 2020-12-04 13:41:13 | <vrs> | TopicSpaces is good |
| 2020-12-04 14:40:13 | × | geekosaur quits (82659a09@host154-009.vpn.uakron.edu) (Remote host closed the connection) |
| 2020-12-04 15:07:04 | → | berberman joins (~berberman@unaffiliated/berberman) |
| 2020-12-04 15:07:44 | × | berberman_ quits (~berberman@unaffiliated/berberman) (Ping timeout: 240 seconds) |
| 2020-12-04 15:39:16 | × | dxld quits (~dxld@80-109-136-248.cable.dynamic.surfer.at) (Remote host closed the connection) |
| 2020-12-04 15:40:18 | <Hash> | Morning |
| 2020-12-04 15:40:29 | → | dxld joins (~dxld@rush.pub.dxld.at) |
| 2020-12-04 15:40:32 | <Hash> | I just discovered in ##linux dwm and I told him about Xmonad |
| 2020-12-04 15:40:40 | <Hash> | It seems Xmonad is a dwm clone in haskell |
| 2020-12-04 15:41:52 | <Hash> | But a lot better and not C |
| 2020-12-04 15:41:57 | × | cfricke quits (~cfricke@unaffiliated/cfricke) (Quit: WeeChat 2.9) |
| 2020-12-04 15:52:22 | <Solid> | I would be hard pressed to call it a dwm clone at this point |
| 2020-12-04 15:53:04 | <Solid> | but it certainly started out as that |
| 2020-12-04 15:54:09 | <Solid> | I'm quite glad I can enjoy an extensible wm without maintaining an ever diverging fork of some project because "just apply patches lol" |
| 2020-12-04 15:55:07 | → | seschwar joins (~seschwar@unaffiliated/seschwar) |
| 2020-12-04 16:47:36 | <Hash> | Yup |
| 2020-12-04 16:47:43 | <Hash> | That's what I told him. The Xmonad ecosystem is rich |
| 2020-12-04 16:57:38 | → | shadow__ joins (~shadow@pool-71-187-70-139.nwrknj.fios.verizon.net) |
| 2020-12-04 17:00:47 | ← | shadow__ parts (~shadow@pool-71-187-70-139.nwrknj.fios.verizon.net) () |
| 2020-12-04 17:01:29 | → | Shadorain joins (~shadow@pool-71-187-70-139.nwrknj.fios.verizon.net) |
| 2020-12-04 17:01:38 | <Shadorain> | hello friends, i have a strange idea today but i think it would be quite helpful to my workflow atleast, |
| 2020-12-04 17:01:42 | <Shadorain> | im trying to setup a layout that spans across my 3 monitors, it is based off of one workspace and a new window just shrinks the first one from 3 -> 2 mons and puts the new window in on the third mon (if that makes sense) |
| 2020-12-04 17:02:49 | <Shadorain> | as of now i just use a floating scratchpad that is 3 monitors long but it would be nice to have it tilable |
| 2020-12-04 17:09:31 | → | geekosaur joins (82659a09@host154-009.vpn.uakron.edu) |
| 2020-12-04 17:12:13 | → | growpotkin joins (~growpotki@130-45-30-154.dyn.grandenetworks.net) |
| 2020-12-04 17:16:59 | <geekosaur> | we don't really support that, xmonad's model is that a workspace fits on a single monitor. it might be possible to abuse LayoutScreens but you'd get windows split across monitors as well |
| 2020-12-04 17:18:09 | <Shadorain> | thats what i was thinking as well but then when i made a fake floating version of what i wanted, i realized that that floating window only resides on the one workspace |
| 2020-12-04 17:18:24 | <Shadorain> | its just a wider window than normal on that one workspace |
| 2020-12-04 17:19:15 | <Shadorain> | so if my layout would have windows spawn at a wider interval it would work fine afaik |
| 2020-12-04 17:28:22 | <Shadorain> | would just have to trick a layout to think the workspace is 5760x1080 instead of 1920x1080 |
| 2020-12-04 17:28:56 | <geekosaur> | that's more or less what LayoutScreens does |
| 2020-12-04 17:29:36 | <Shadorain> | oh hm ur right, i see that in the second example on the docs |
| 2020-12-04 17:30:41 | <Shadorain> | ooh yes then i can run 3 column layout with this trick |
| 2020-12-04 17:30:49 | <Shadorain> | each monitor would be a column |
| 2020-12-04 17:41:03 | <Shadorain> | woah it actually worked haha!!! this is nuts! |
| 2020-12-04 17:46:44 | <Shadorain> | the only issue im having is that it goes past just the one workspace and affects all |
| 2020-12-04 17:50:13 | <geekosaur> | yes, I think there's no way around that since workspaces are subordinate to monitors and not vice versa |
| 2020-12-04 17:50:29 | <geekosaur> | you can't re-layout monitors based on what workspace is visible |
| 2020-12-04 18:03:47 | × | novas0x2a quits (~blah@157-131-125-210.fiber.dynamic.sonic.net) (Read error: Connection reset by peer) |
| 2020-12-04 18:03:57 | → | novas0x2a joins (~blah@157-131-125-210.fiber.dynamic.sonic.net) |
| 2020-12-04 18:06:17 | <Shadorain> | hmm but u can rescreen on layout change |
| 2020-12-04 18:06:46 | <Shadorain> | and prob can do a hack where if u use a workspace change key to also rescreen |
| 2020-12-04 18:09:02 | × | Rockj quits (~rockj@2001:67c:550:feed::1) (Ping timeout: 264 seconds) |
| 2020-12-04 18:10:15 | <geekosaur> | you may cause an infinite loop if you do, since rescreen would rerun the layout |
| 2020-12-04 18:10:56 | <Shadorain> | i cant find a way to do the layoutScreens in the layout itself so i have a bind but id much rather it in the layout |
| 2020-12-04 18:19:53 | <sfrique> | Can the layout be changed dynamically based on monitor resolution/orientation? if so how, i plan to use xmonad as my second WM (i3 first) and see if i feel it's improving my workflow |
| 2020-12-04 18:20:59 | <Shadorain> | yes it can there is a module called PerScreen that handles that well |
| 2020-12-04 18:23:32 | <geekosaur> | there are a couple ofways to conditionalize layouts based on screen size iirc |
| 2020-12-04 18:27:11 | <Shadorain> | yo geekosaur, is there a max delta ratio limit for how little you inc/dec with resizing? |
| 2020-12-04 18:27:30 | <Shadorain> | im trying like (1/1000) and it isnt any different from (1/100) |
All times are in UTC.