Home liberachat/#xmonad: Logs Calendar

Logs on 2026-02-02 (liberachat/#xmonad)

03:41:50 × terrorjack quits (~terrorjac@2a01:4f8:271:2d98::2) (Quit: The Lounge - https://thelounge.chat)
04:21:49 → werneta joins (~werneta@71.83.160.242)
05:13:05 × werneta quits (~werneta@71.83.160.242) (Quit: Lost terminal)
06:01:10 → ChubaDuba joins (~ChubaDuba@46.147.119.19)
06:01:56 × ChubaDuba quits (~ChubaDuba@46.147.119.19) (Client Quit)
06:05:34 × deepy quits (deepy@user/deepy) (Read error: Connection reset by peer)
06:07:06 → deepy joins (deepy@user/deepy)
07:05:59 → rekahsoft joins (~rekahsoft@59.26-246-81.adsl-static.isp.belgacom.be)
08:32:28 × rekahsoft quits (~rekahsoft@59.26-246-81.adsl-static.isp.belgacom.be) (Ping timeout: 255 seconds)
11:25:57 → Enrico63 joins (~Enrico63@148.252.128.12)
11:41:22 × Enrico63 quits (~Enrico63@148.252.128.12) (Quit: Client closed)
11:47:15 Digitteknohippie is now known as Digit
12:49:06 → terrorjack joins (~terrorjac@2a01:4f8:271:2d98::2)
12:51:36 × terrorjack quits (~terrorjac@2a01:4f8:271:2d98::2) (Client Quit)
13:10:50 → Digitteknohippie joins (~user@user/digit)
13:12:12 × Digit quits (~user@user/digit) (Ping timeout: 252 seconds)
13:51:35 → terrorjack joins (~terrorjac@2a01:4f8:271:2d98::2)
15:02:19 → Enrico63 joins (~Enrico63@148.252.128.12)
15:16:20 × L29Ah quits (~L29Ah@wikipedia/L29Ah) (Quit: Gateway shutdown)
15:37:08 → L29Ah joins (~L29Ah@wikipedia/L29Ah)
15:41:11 → ChubaDuba joins (~ChubaDuba@109.195.234.244)
15:45:39 × ChubaDuba quits (~ChubaDuba@109.195.234.244) (Ping timeout: 260 seconds)
15:57:48 × Enrico63 quits (~Enrico63@148.252.128.12) (Quit: Client closed)
16:32:24 × Digitteknohippie quits (~user@user/digit) (Ping timeout: 252 seconds)
16:47:48 → ChubaDuba joins (~ChubaDuba@109.195.234.244)
16:52:08 × ChubaDuba quits (~ChubaDuba@109.195.234.244) (Ping timeout: 240 seconds)
16:52:14 → ChubaDuba joins (~ChubaDuba@109.195.234.244)
17:04:11 × ChubaDuba quits (~ChubaDuba@109.195.234.244) (Quit: WeeChat 4.8.1)
17:06:32 → ChubaDuba joins (~ChubaDuba@109.195.234.244)
17:06:58 × ft quits (~ft@p508db4c0.dip0.t-ipconnect.de) (Quit: Lost terminal)
17:07:06 → Digit joins (~user@user/digit)
17:08:50 → ft joins (~ft@p508db4c0.dip0.t-ipconnect.de)
17:10:31 × ChubaDuba quits (~ChubaDuba@109.195.234.244) (Ping timeout: 240 seconds)
17:11:21 → ChubaDuba joins (~ChubaDuba@109.195.234.244)
17:13:50 Digit is now known as digitteknohippie
17:14:40 digitteknohippie is now known as Digit
17:15:20 × ChubaDuba quits (~ChubaDuba@109.195.234.244) (Ping timeout: 240 seconds)
17:57:06 × ml| quits (~ml|@user/ml/x-5298235) (Ping timeout: 252 seconds)
18:11:25 → ml| joins (~ml|@user/ml/x-5298235)
18:27:01 × ml| quits (~ml|@user/ml/x-5298235) (Ping timeout: 264 seconds)
18:40:41 → ml| joins (~ml|@user/ml/x-5298235)
19:29:36 → attheo joins (~atta@120.sub-75-233-234.myvzw.com)
19:37:20 → ChubaDuba joins (~ChubaDuba@109.195.234.244)
19:37:20 → Digitteknohippie joins (~user@user/digit)
19:37:46 × Digit quits (~user@user/digit) (Ping timeout: 256 seconds)
19:50:32 × ml| quits (~ml|@user/ml/x-5298235) (Ping timeout: 240 seconds)
20:01:10 × attheo quits (~atta@120.sub-75-233-234.myvzw.com) (Quit: leaving)
20:04:13 → ml| joins (~ml|@user/ml/x-5298235)
21:27:04 <haskellbridge> <nemme> Heya
21:27:04 <haskellbridge> ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/bJmhnSdYVFZpYDjjtmiFLZBe/qL_nwvBtQEg (3 lines)
21:39:07 <haskellbridge> <geekosaur> it's been started several times and never finished. most recent attempt was https://discourse.haskell.org/t/haskell-wlroots-bindings/8426 and https://discourse.haskell.org/t/tiny-wlhs-a-hybrid-haskell-and-c-wayland-compositor/10803
21:41:37 <haskellbridge> <geekosaur> liskin suggested (https://matrix.to/#/%21arvCkuMSDjUpxdkOoH%3Amatrix.org/%24CviURgZwDPgU4Cg0slJEH8nP4cvp5-t_1zIwhx0Sk-w?via=matrix.org&via=kf8nh.com&via=hashi.sbs) smithay as an alternative starting point but I don't think anyone's taken him up on it yet
21:43:45 <liskin> Another idea I had the other day to was to invite people to meet me somewhere in London and try hacking on it together
21:44:37 <liskin> But I'll probably need to wait a few more months until I'm out of the worst bit of burnout
21:44:47 <liskin> I have time, but not energy
21:46:10 <liskin> (surely there must be someone in London who'd be interested, but then, maybe not, it's not exactly the right place for free software enthusiasts, or is it?)
21:46:51 <haskellbridge> <geekosaur> central europe and asia look to be the real hotbeds to me
21:48:47 <haskellbridge> <nemme> geekosaur: I'm glad that there are at least attempts
21:49:42 <haskellbridge> <nemme> X11 just doesn't have low enough latency for me, so I was kinda forced to switch to wl
21:50:07 <liskin> geekosaur: yeah that's my view as well - probably socioeconomic reasons or something
21:51:47 <haskellbridge> <n​emme> I'll probably use niri for the time being, which also uses smithay instead of wl-roots
21:52:27 <haskellbridge> <n​emme> +(with disabled animations)
21:54:38 <haskellbridge> <g​eekosaur> sadly we've been collecting donations with an eye toward helping pay for a wayland port, but we don't have enough to actually pay someone to sit down and write it for us
21:56:29 <haskellbridge> <n​emme> Hmm... would be an awesome project tho
21:57:32 <haskellbridge> <g​eekosaur> no, that's something else 😀 more seriously, with the number of times it's derailed I sometimes wonder if it's worth doing
21:58:19 <haskellbridge> <g​eekosaur> especially since I know a number of people have considered pitching in and deciding not to because there's no way to make the existing contribs compatible with it and wayland doesn't support some of the things most people expect from xmonad
22:00:30 <haskellbridge> <n​emme> Well, maybe we should wait until pheonix (modern upgrade of X11) gets released
22:01:06 <haskellbridge> <g​eekosaur> an alternative path forward there is wayland-x11, but I think it and xwayland still have shortcomings
22:01:19 <haskellbridge> <g​eekosaur> that said, they seem to be being worked on
22:03:51 <haskellbridge> <n​emme> * (https://git.dec05eba.com/phoenix/about/)
22:04:42 <haskellbridge> <g​eekosaur> hm, phoenix sounds in theory like a good idea, but I have to wonder if they've really examined the protocol. it's oriented toward ancient graphics workstations where every monitor had its own independent framebuffer card, and it shows
22:06:50 <haskellbridge> <g​eekosaur> reading on, I guess they have to some extent. but blithely talking about extending xrandr for various things (in particular per-screen dpi) makes me think they haven't yet realized just how much of a godawful hack xrandr is
22:07:34 <haskellbridge> <g​eekosaur> (because core x11 is actively antagonistic to its goals, being based on the assumption that every monitor is independent and requires a separate "Screen" _in hardware_)
22:09:47 Digitteknohippie is now known as Digit
22:11:02 <haskellbridge> <T​ranquil Ity> geekosaur: Why Smithay
22:11:46 <haskellbridge> <g​eekosaur> I think just because it's not wlroots
22:11:56 <haskellbridge> <g​eekosaur> and wlroots has been the death of every other attempt
22:12:07 <haskellbridge> <T​ranquil Ity> geekosaur: What are the things missing from the existing protos?
22:12:53 <haskellbridge> <T​ranquil Ity> geekosaur: Makes sense
22:13:00 <haskellbridge> <g​eekosaur> "appName"/"className" is a big one (i.e. no useful "ManageHook"since titles are unreliable)
22:13:36 <haskellbridge> <g​eekosaur> there's a limited version of "appName" that _some_ (not all) apps bother to set
22:13:49 <haskellbridge> <g​eekosaur> "appName"/"className" is a big one (i.e. no useful "ManageHook" since titles are unreliable)
22:14:17 <haskellbridge> <T​ranquil Ity> Titles are unreliable? Unsure I follow
22:14:17 <haskellbridge> ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/hMQQhPAsBjCDztueNxqwmBHV/TDltYb22fuY (3 lines)
22:14:30 <haskellbridge> <g​eekosaur> and I don't think wayland apps have an equivalent of "WM_WINDOW_ROLE" either
22:15:01 <haskellbridge> <g​eekosaur> titles change too often, and aren't set at all (or are set to internal hashes or etc.) when browser windows are mapped
22:16:06 <haskellbridge> <g​eekosaur> basically trying to control a window by title can get you into a game of whack-a-mole
22:16:20 <haskellbridge> <g​eekosaur> +in your "ManageHook"
22:17:30 × ChubaDuba quits (~ChubaDuba@109.195.234.244) (Quit: WeeChat 4.8.1)
22:19:15 <haskellbridge> <T​ranquil Ity> geekosaur: Browser window titles _should_ be consistent (-ish, given it's a title)
22:19:15 <haskellbridge> But yea seems like there's no equivalent of WM_WINDOW_ROLE that I know of (after reading the ICCCM section defining it for X11)
22:20:48 <haskellbridge> <g​eekosaur> browsers don't set the title until after the JS runs, but the window has to be mapped for the JS to work since it may draw things
22:21:02 <haskellbridge> <g​eekosaur> so the title at map time is something unusaful
22:21:09 <haskellbridge> <g​eekosaur> * unusdful
22:21:13 <haskellbridge> <g​eekosaur> * unuseful
22:21:18 <haskellbridge> <T​ranquil Ity> geekosaur: What specifically caused the death? I'm kinda skeptical a compositor framework that relies a lot on Rust traits and such is a good choice (will need lots of Rust glue to hammer it into shape for use by Haskell)
22:21:21 <haskellbridge> I was skeptical of wlroots being a good idea before as well, to be clear, but with Smithay it's uh
22:22:05 <haskellbridge> <T​ranquil Ity> geekosaur: You mean on X11?
22:22:12 <haskellbridge> <g​eekosaur> the early waymonad attempt was too crashy because of limitations in the early wlroots version it was using. I don't know what killed the later ones; the devs just went silent
22:22:50 <haskellbridge> <T​ranquil Ity> Ah
22:23:14 <haskellbridge> <g​eekosaur> Tranquil Ity: it'd be true on wayland as well, you don't want the window manager moving the window around after it's been presented unless the user specifically requests it
22:23:47 <haskellbridge> <T​ranquil Ity> Usually compositors don't show toplevels until they have a complete buffer attached
22:24:21 <haskellbridge> <T​ranquil Ity> So, at least one full frame to show
22:24:28 <haskellbridge> <T​ranquil Ity> Presumably by then the title has already been set
22:24:46 <haskellbridge> <g​eekosaur> browsers require that buffer to be set up before they can run the JS that might draw in them
22:25:39 <haskellbridge> <T​ranquil Ity> I don't follow how that relates
22:26:07 <haskellbridge> <T​ranquil Ity> You alloc a buffer, draw to it, attach it
22:26:08 <haskellbridge> (Or optionally send a syncobj to the compositor to wait on with the actual attaching)
22:26:20 <haskellbridge> <T​ranquil Ity> The buffer must contain a finished frame
22:28:22 <haskellbridge> <T​ranquil Ity> I would say if the browser attaches a complete rendered frame but hasn't set a title then that's a bug
22:35:15 <haskellbridge> <T​ranquil Ity> Like, there's no space where the top-level is in a state of _visible but still drawing the first frame_, if there is that's a bug
22:35:58 <haskellbridge> <T​ranquil Ity> Unlike X11
22:43:36 <haskellbridge> <g​eekosaur> that leads to users complaining the system isn't responsive
22:43:51 <haskellbridge> <g​eekosaur> the browser has to do _something_ immediately
22:52:20 <haskellbridge> <T​ranquil Ity> Have you tested it on WL?
22:52:20 <haskellbridge> I'm curious, I should test if they just draw a buffer that's just a solid color and send that or smth
22:53:44 <haskellbridge> <T​ranquil Ity> (To be clear, browsers have never been responsive to me)
23:03:21 <haskellbridge> <g​eekosaur> that's the problem. they'd look even less responsive if double-buffered
23:03:48 <haskellbridge> <g​eekosaur> (and let's face it, anything that complex written mostly in JS is going to have sucky responsiveness…)
23:04:53 <haskellbridge> <g​eekosaur> (see also: electron apps)

All times are in UTC on 2026-02-02.