2021/03/28

2021-03-28 00:04:20 +0100xaltsc(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 268 seconds)
2021-03-28 00:32:47 +0100notis(~notis@130.43.124.71.dsl.dyn.forthnet.gr) (Ping timeout: 246 seconds)
2021-03-28 00:33:12 +0100notis(~notis@85.203.44.154)
2021-03-28 00:36:48 +0100seschwar(~seschwar@unaffiliated/seschwar) (Quit: :wq)
2021-03-28 03:20:37 +0200notis(~notis@85.203.44.154) (Ping timeout: 268 seconds)
2021-03-28 03:40:56 +0200gazler_(~gazler@195.107.2.81.in-addr.arpa)
2021-03-28 03:42:46 +0200gazler(~gazler@195.107.2.81.in-addr.arpa) (Ping timeout: 240 seconds)
2021-03-28 03:50:47 +0200s00pcan(~chris@075-133-056-178.res.spectrum.com)
2021-03-28 06:03:18 +0200materiyolo(~materiyol@112.204.174.249)
2021-03-28 06:52:02 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net) (Read error: Connection reset by peer)
2021-03-28 06:52:47 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net)
2021-03-28 06:52:53 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net) (Read error: Connection reset by peer)
2021-03-28 06:53:17 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net)
2021-03-28 06:54:24 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net) (Read error: Connection reset by peer)
2021-03-28 06:55:51 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net)
2021-03-28 06:58:54 +0200materiyolo(~materiyol@112.204.174.249) (Ping timeout: 268 seconds)
2021-03-28 07:06:56 +0200palo1(~weechat@c-base/crew/palo)
2021-03-28 07:09:50 +0200palo(~weechat@c-base/crew/palo) (Ping timeout: 246 seconds)
2021-03-28 07:09:51 +0200palo1palo
2021-03-28 07:26:24 +0200growpotkin(~growpotki@130-45-30-154.dyn.grandenetworks.net) (Quit: ZNC 1.8.2 - https://znc.in)
2021-03-28 07:38:46 +0200dexterfoo(dexter@2a01:7e00::f03c:91ff:fe86:59ec) (Quit: WeeChat 1.9.1)
2021-03-28 08:37:31 +0200xaltsc(~xaltsc@unaffiliated/xaltsc)
2021-03-28 08:53:53 +0200thoros(~thoros@194-166-47-167.hdsl.highway.telekom.at)
2021-03-28 08:54:09 +0200idhugo_(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net)
2021-03-28 09:30:31 +0200thoros(~thoros@194-166-47-167.hdsl.highway.telekom.at) (Quit: WeeChat 3.0.1)
2021-03-28 09:31:05 +0200thoros(~thoros@194-166-47-167.hdsl.highway.telekom.at)
2021-03-28 10:07:34 +0200ADG1089(~aditya@27.58.165.185)
2021-03-28 10:26:35 +0200idhugo_(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 265 seconds)
2021-03-28 10:29:14 +0200lampilelo(~user@178-36-127-105.adsl.inetia.pl)
2021-03-28 10:29:37 +0200idhugo_(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net)
2021-03-28 10:38:06 +0200 <lampilelo> i'm very new to xmonad and trying to figure out how to enable the fullscreen functionality for windows that request it, i tried some solutions from stackoverflow but nothing seems to work and the mpv window stays the same after pressing f; here's my config: https://dpaste.com/G2S9XHQQ7
2021-03-28 10:44:15 +0200wonko7(~wonko7@62.115.229.50)
2021-03-28 10:57:10 +0200 <coldpress> lampilelo: I'm confused, do you want a window to become fullscreen automatically, or do you want to press a key to make a window fullscreen?
2021-03-28 10:59:34 +0200 <lampilelo> i want it to go fullscreen when i click on a gui button that should make it fullscreen, pressing a key if the program has a keybinding for it should do it too
2021-03-28 10:59:51 +0200 <lampilelo> and regardless of the layout it's in
2021-03-28 11:06:38 +0200 <coldpress> I know xmonad can set whether a window floats at startup, but I don't know how a window requests to become fullscreen after startup
2021-03-28 11:06:59 +0200 <coldpress> maybe someone else can help you
2021-03-28 11:10:17 +0200 <lampilelo> i certainly hope so
2021-03-28 11:17:05 +0200notis(~notis@85.203.44.87)
2021-03-28 11:19:18 +0200 <Solid> coldpress: they'd set things like _NET_WM_STATE_FULLSCREEN
2021-03-28 11:20:12 +0200 <Solid> I'm surprised that fullscreenEventHook doesn't seem to have any effect with mpv
2021-03-28 11:20:35 +0200 <Solid> lampilelo: I would tell you to use ewmhFullscreen instead but I think that that's still not in any released version :/
2021-03-28 11:28:40 +0200 <lampilelo> Solid: yeah, it doesn't set it, it just sets _NET_WM_BYPASS_COMPOSITOR, WM_SIZE_HINTS and _MOTIF_WM_HINTS
2021-03-28 11:30:16 +0200 <lampilelo> so what i need to do is make a custom hook for handleEventHook?
2021-03-28 11:30:59 +0200 <Solid> lampilelo: it does set `_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN` for me when it goes fullscreen
2021-03-28 11:33:33 +0200mc47(~yecinem@196.179.190.248)
2021-03-28 11:34:22 +0200 <lampilelo> that's strange
2021-03-28 11:40:58 +0200 <lampilelo> it works when i launch mpv with --x11-netw=yes
2021-03-28 11:41:56 +0200 <lampilelo> it's funny because in the docs for this option they wrote "This may or may not help with broken window managers."
2021-03-28 11:41:56 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net) (Read error: Connection reset by peer)
2021-03-28 11:43:03 +0200 <Solid> oh yeah that part of the manual is pretty funny
2021-03-28 11:43:11 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net)
2021-03-28 11:43:33 +0200 <Solid> but it's weird because with that fullscreenEventHook we _should_ correctly advertise fullscreen support
2021-03-28 11:44:49 +0200 <Liskni_si> Event hooks don't advertise stuff
2021-03-28 11:45:05 +0200 <lampilelo> maybe something in my config interferes with it
2021-03-28 11:45:19 +0200 <Liskni_si> ewmhFullscreen does, and isn't released yet
2021-03-28 11:45:28 +0200 <Liskni_si> That's all there is to it
2021-03-28 11:46:22 +0200 <lampilelo> so the workaround would be to just add this option to my mpv config
2021-03-28 11:51:23 +0200 <Solid> oh
2021-03-28 11:52:51 +0200 <lampilelo> ok, thanks guys, it was really annoying me
2021-03-28 11:53:39 +0200 <lampilelo> i'll make sure to use ewmhFullscreen after the next release
2021-03-28 12:03:36 +0200seschwar(~seschwar@unaffiliated/seschwar)
2021-03-28 12:05:37 +0200mc47(~yecinem@196.179.190.248) (Read error: Connection reset by peer)
2021-03-28 12:06:07 +0200mc47(~yecinem@196.179.190.248)
2021-03-28 12:08:17 +0200ADG1089(~aditya@27.58.165.185) (Remote host closed the connection)
2021-03-28 12:25:15 +0200materiyolo(~materiyol@112.204.174.249)
2021-03-28 12:32:28 +0200hexo(~hexo@83.167.228.130) (Read error: Connection reset by peer)
2021-03-28 12:32:28 +0200hacxmanhexo
2021-03-28 12:36:01 +0200hexo-(~hexo@2a01:430:17:1::ffff:328)
2021-03-28 13:06:49 +0200mc47(~yecinem@196.179.190.248) (Remote host closed the connection)
2021-03-28 13:16:58 +0200wonko7(~wonko7@62.115.229.50) (Ping timeout: 240 seconds)
2021-03-28 13:32:18 +0200materiyolo(~materiyol@112.204.174.249) (Ping timeout: 240 seconds)
2021-03-28 13:38:15 +0200wonko7(~wonko7@45.15.17.60)
2021-03-28 14:42:25 +0200materiyolo(~materiyol@112.204.174.249)
2021-03-28 14:50:32 +0200ADG1089(~aditya@27.58.165.185)
2021-03-28 14:53:08 +0200_ashbreeze_(~mark@64.85.214.234.reverse.socket.net) (Remote host closed the connection)
2021-03-28 14:54:40 +0200_ashbreeze_(~mark@64.85.214.234.reverse.socket.net)
2021-03-28 14:57:03 +0200geekosaur(ae68c070@cpe-174-104-192-112.neo.res.rr.com)
2021-03-28 15:00:31 +0200lampilelo(~user@178-36-127-105.adsl.inetia.pl) (Ping timeout: 268 seconds)
2021-03-28 15:52:34 +0200ADG1089(~aditya@27.58.165.185) (Remote host closed the connection)
2021-03-28 15:56:42 +0200wonko7(~wonko7@45.15.17.60) (Ping timeout: 252 seconds)
2021-03-28 16:02:52 +0200 <Solid> what do people think about something like an XMonad.Internal.[Util,Prelude] or something for gathering small functions so they don't have to be re-defined on a per-module basis?
2021-03-28 16:03:07 +0200 <Solid> perhaps even for all the base imports that everyone needs all the time anyways
2021-03-28 16:05:13 +0200 <geekosaur> historically that's more or less "import XMonad"
2021-03-28 16:05:38 +0200 <geekosaur> unless you mean something specific to contrib
2021-03-28 16:06:33 +0200idhugo_(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Remote host closed the connection)
2021-03-28 16:07:00 +0200idhugo_(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net)
2021-03-28 16:09:07 +0200deppy(~deppy@gateway/tor-sasl/deppy)
2021-03-28 16:09:28 +0200 <deppy> is there a way to have a seperate set of workspaces for each screen?
2021-03-28 16:09:35 +0200 <deppy> instead of sharing them between screens
2021-03-28 16:09:53 +0200 <Solid> I mean something more-or-less internal to contrib yeah
2021-03-28 16:10:50 +0200 <Liskni_si> deppy: IndependentScreens probably
2021-03-28 16:12:33 +0200 <deppy> seems like what I want
2021-03-28 16:19:01 +0200deppy(~deppy@gateway/tor-sasl/deppy) (Quit: deppy)
2021-03-28 16:19:39 +0200notis(~notis@85.203.44.87) (Ping timeout: 246 seconds)
2021-03-28 16:20:34 +0200idhugo_(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 260 seconds)
2021-03-28 16:21:40 +0200notis(~notis@130.43.124.71.dsl.dyn.forthnet.gr)
2021-03-28 16:26:02 +0200_ashbreeze_(~mark@64.85.214.234.reverse.socket.net) (Remote host closed the connection)
2021-03-28 16:27:29 +0200_ashbreeze_(~mark@64.85.214.234.reverse.socket.net)
2021-03-28 16:29:37 +0200deppy(~deppy@gateway/tor-sasl/deppy)
2021-03-28 16:31:09 +0200 <deppy> well, independet screens worked but now my bar is kind of funny looking haha
2021-03-28 16:31:26 +0200 <geekosaur> there's extra work needed for bars to behave, yes
2021-03-28 16:31:42 +0200 <geekosaur> which is improved with some changes in PRs
2021-03-28 17:09:22 +0200_ashbreeze_(~mark@64.85.214.234.reverse.socket.net) (Remote host closed the connection)
2021-03-28 17:10:35 +0200_ashbreeze_(~mark@64.85.214.234.reverse.socket.net)
2021-03-28 17:15:05 +0200kelnoky(~shao@ip1f128ba7.dynamic.kabel-deutschland.de)
2021-03-28 17:48:40 +0200lampilelo(~user@178-36-127-105.adsl.inetia.pl)
2021-03-28 18:09:14 +0200idhugo_(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net)
2021-03-28 18:14:47 +0200idhugo_(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 268 seconds)
2021-03-28 18:21:26 +0200deppy(~deppy@gateway/tor-sasl/deppy) (Quit: deppy)
2021-03-28 18:24:34 +0200ADG1089(~aditya@27.58.165.185)
2021-03-28 18:44:56 +0200ADG1089(~aditya@27.58.165.185) (Quit: Konversation terminated!)
2021-03-28 18:52:44 +0200mc47(~yecinem@196.179.190.248)
2021-03-28 18:53:45 +0200 <mc47> Solid that could be useful, some things feel repetitive throughout contrib
2021-03-28 18:56:14 +0200 <geekosaur> yeh, originally I was thinking of io but things like fi happen all over the place
2021-03-28 18:57:06 +0200 <geekosaur> mostly because of X11 being designed with the assumption of a C compiler and its automatic typecasting/promotion
2021-03-28 18:58:54 +0200notis(~notis@130.43.124.71.dsl.dyn.forthnet.gr) (Ping timeout: 246 seconds)
2021-03-28 18:59:18 +0200notis(~notis@85.203.44.87)
2021-03-28 19:00:11 +0200materiyolo(~materiyol@112.204.174.249) (Quit: WeeChat 3.0.1)
2021-03-28 19:02:09 +0200abhixec(~abhixec@c-67-169-139-16.hsd1.ca.comcast.net)
2021-03-28 19:04:15 +0200 <mc47> things like (.:) might go there two, I've seen it ina couple of modules
2021-03-28 19:04:31 +0200 <mc47> (.:) = (.) . (.) :)
2021-03-28 19:14:04 +0200mc47(~yecinem@196.179.190.248) (Remote host closed the connection)
2021-03-28 19:14:23 +0200mc47(~yecinem@196.179.190.248)
2021-03-28 19:17:04 +0200growpotkin(~growpotki@130-45-30-154.dyn.grandenetworks.net)
2021-03-28 19:18:01 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net) (Read error: Connection reset by peer)
2021-03-28 19:19:49 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net)
2021-03-28 19:20:38 +0200geekosauris more inclined to rewrite those to be pointful
2021-03-28 19:20:56 +0200 <geekosaur> owls are a bit too inscrutable :)
2021-03-28 19:21:57 +0200 <Solid> I actually also had the multivariant composition example in mind, because I need that in yet another module :D
2021-03-28 19:22:15 +0200 <Solid> though it is perhaps a bit inscrutable
2021-03-28 19:22:23 +0200 <Solid> but yeah things like fi = fromIntegral certainly happen all over the place
2021-03-28 19:22:36 +0200 <Solid> I'll cook something up later I suppose
2021-03-28 19:24:57 +0200 <mc47> It feels like something arcane whenever I write it pointfree :)
2021-03-28 19:26:21 +0200 <Solid> it only gets arcane if you actually define arbitrary multivariant composition :>
2021-03-28 19:32:06 +0200 <mc47> Unrelated, but what do you think about having a combinator that broadcasts DestroyWindowEvent to layouts?
2021-03-28 19:33:17 +0200 <mc47> This came up in #474, and apparently many layouts/layout modifiers don't do proper garbage collection
2021-03-28 19:39:32 +0200 <geekosaur> it might be worth simply rebroadcasting it from the core
2021-03-28 19:39:47 +0200 <geekosaur> layouts that don't care will simply ignore it anyway
2021-03-28 19:40:06 +0200xaltsc_(~xaltsc@unaffiliated/xaltsc)
2021-03-28 19:40:38 +0200xaltsc(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 240 seconds)
2021-03-28 19:44:26 +0200xaltsc_(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 246 seconds)
2021-03-28 19:46:19 +0200xaltsc_(~xaltsc@unaffiliated/xaltsc)
2021-03-28 19:47:28 +0200dexterfoo(dexter@2a01:7e00::f03c:91ff:fe86:59ec)
2021-03-28 20:05:31 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Quit: Lost terminal)
2021-03-28 20:14:01 +0200thoros(~thoros@194-166-47-167.hdsl.highway.telekom.at) (Quit: WeeChat 3.0.1)
2021-03-28 20:22:24 +0200idhugo_(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net)
2021-03-28 20:35:36 +0200mc47(~yecinem@196.179.190.248) (Remote host closed the connection)
2021-03-28 20:41:38 +0200 <geekosaur> come to think of it, would that also simplify dock cleanup?
2021-03-28 20:51:37 +0200rafadc(~rafadc@213.37.16.152.dyn.user.ono.com) (Ping timeout: 245 seconds)
2021-03-28 20:52:46 +0200rafadc(~rafadc@213.37.16.152.dyn.user.ono.com)
2021-03-28 20:56:28 +0200 <Liskni_si> since the broadcast is guarded by isClient, it wouldn't
2021-03-28 20:56:58 +0200rafadc(~rafadc@213.37.16.152.dyn.user.ono.com) (Ping timeout: 240 seconds)
2021-03-28 20:58:32 +0200rafadc(~rafadc@213.37.16.152.dyn.user.ono.com)
2021-03-28 20:58:42 +0200 <Liskni_si> re custom prelude: I'm somewhat sceptical of it being a good tradeoff. saves some typing here and there, but it's alien to people unfamiliar with the codebase (applies to any alternative prelude actually, I really wish haskell's stdlib wasn't crap)
2021-03-28 21:00:22 +0200 <Solid> well, it would be mostly just re-exporting many parts of base
2021-03-28 21:00:28 +0200 <Solid> which I would expect people to be familiar with
2021-03-28 21:01:10 +0200 <Liskni_si> that may be okay-ish, possibly
2021-03-28 21:16:27 +0200xaltsc_(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 246 seconds)
2021-03-28 21:18:34 +0200xaltsc_(~xaltsc@unaffiliated/xaltsc)
2021-03-28 21:27:43 +0200 <mc47[m]> geekosaur it might work, but I guess it's not necessary
2021-03-28 21:34:40 +0200xaltsc_(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 276 seconds)
2021-03-28 21:36:11 +0200idhugo_(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 240 seconds)
2021-03-28 21:37:01 +0200xaltsc(~xaltsc@unaffiliated/xaltsc)
2021-03-28 21:41:34 +0200geekosaur(ae68c070@cpe-174-104-192-112.neo.res.rr.com) (Quit: Connection closed)
2021-03-28 21:45:58 +0200xaltsc(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 240 seconds)
2021-03-28 21:48:14 +0200xaltsc(~xaltsc@unaffiliated/xaltsc)
2021-03-28 22:43:18 +0200notis(~notis@85.203.44.87) (Ping timeout: 240 seconds)
2021-03-28 22:45:40 +0200notis(~notis@130.43.124.71.dsl.dyn.forthnet.gr)
2021-03-28 22:51:11 +0200xaltsc(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 240 seconds)
2021-03-28 22:53:23 +0200xaltsc(~xaltsc@unaffiliated/xaltsc)
2021-03-28 22:55:36 +0200abhixec(~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Quit: leaving)
2021-03-28 23:15:48 +0200xaltsc(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 246 seconds)
2021-03-28 23:58:47 +0200kelnoky(~shao@ip1f128ba7.dynamic.kabel-deutschland.de) (Quit: WeeChat 3.1)