IRCBrowse

2026/02/02

2026-02-02 04:41:50 +0100terrorjack(~terrorjac@2a01:4f8:271:2d98::2) (Quit: The Lounge - https://thelounge.chat)
2026-02-02 05:21:49 +0100werneta(~werneta@71.83.160.242) werneta
2026-02-02 06:13:05 +0100werneta(~werneta@71.83.160.242) (Quit: Lost terminal)
2026-02-02 07:01:10 +0100ChubaDuba(~ChubaDuba@46.147.119.19) ChubaDuba
2026-02-02 07:01:56 +0100ChubaDuba(~ChubaDuba@46.147.119.19) (Client Quit)
2026-02-02 07:05:34 +0100deepy(deepy@user/deepy) (Read error: Connection reset by peer)
2026-02-02 07:07:06 +0100deepy(deepy@user/deepy) deepy
2026-02-02 08:05:59 +0100rekahsoft(~rekahsoft@59.26-246-81.adsl-static.isp.belgacom.be) rekahsoft
2026-02-02 09:32:28 +0100rekahsoft(~rekahsoft@59.26-246-81.adsl-static.isp.belgacom.be) (Ping timeout: 255 seconds)
2026-02-02 12:25:57 +0100Enrico63(~Enrico63@148.252.128.12) Enrico63
2026-02-02 12:41:22 +0100Enrico63(~Enrico63@148.252.128.12) (Quit: Client closed)
2026-02-02 12:47:15 +0100DigitteknohippieDigit
2026-02-02 13:49:06 +0100terrorjack(~terrorjac@2a01:4f8:271:2d98::2) terrorjack
2026-02-02 13:51:36 +0100terrorjack(~terrorjac@2a01:4f8:271:2d98::2) (Client Quit)
2026-02-02 14:10:50 +0100Digitteknohippie(~user@user/digit) Digit
2026-02-02 14:12:12 +0100Digit(~user@user/digit) (Ping timeout: 252 seconds)
2026-02-02 14:51:35 +0100terrorjack(~terrorjac@2a01:4f8:271:2d98::2) terrorjack
2026-02-02 16:02:19 +0100Enrico63(~Enrico63@148.252.128.12) Enrico63
2026-02-02 16:16:20 +0100L29Ah(~L29Ah@wikipedia/L29Ah) (Quit: Gateway shutdown)
2026-02-02 16:37:08 +0100L29Ah(~L29Ah@wikipedia/L29Ah) L29Ah
2026-02-02 16:41:11 +0100ChubaDuba(~ChubaDuba@109.195.234.244) ChubaDuba
2026-02-02 16:45:39 +0100ChubaDuba(~ChubaDuba@109.195.234.244) (Ping timeout: 260 seconds)
2026-02-02 16:57:48 +0100Enrico63(~Enrico63@148.252.128.12) (Quit: Client closed)
2026-02-02 17:32:24 +0100Digitteknohippie(~user@user/digit) (Ping timeout: 252 seconds)
2026-02-02 17:47:48 +0100ChubaDuba(~ChubaDuba@109.195.234.244) ChubaDuba
2026-02-02 17:52:08 +0100ChubaDuba(~ChubaDuba@109.195.234.244) (Ping timeout: 240 seconds)
2026-02-02 17:52:14 +0100ChubaDuba(~ChubaDuba@109.195.234.244) ChubaDuba
2026-02-02 18:04:11 +0100ChubaDuba(~ChubaDuba@109.195.234.244) (Quit: WeeChat 4.8.1)
2026-02-02 18:06:32 +0100ChubaDuba(~ChubaDuba@109.195.234.244) ChubaDuba
2026-02-02 18:06:58 +0100ft(~ft@p508db4c0.dip0.t-ipconnect.de) (Quit: Lost terminal)
2026-02-02 18:07:06 +0100Digit(~user@user/digit) Digit
2026-02-02 18:08:50 +0100ft(~ft@p508db4c0.dip0.t-ipconnect.de) ft
2026-02-02 18:10:31 +0100ChubaDuba(~ChubaDuba@109.195.234.244) (Ping timeout: 240 seconds)
2026-02-02 18:11:21 +0100ChubaDuba(~ChubaDuba@109.195.234.244) ChubaDuba
2026-02-02 18:13:50 +0100Digitdigitteknohippie
2026-02-02 18:14:40 +0100digitteknohippieDigit
2026-02-02 18:15:20 +0100ChubaDuba(~ChubaDuba@109.195.234.244) (Ping timeout: 240 seconds)
2026-02-02 18:57:06 +0100ml|(~ml|@user/ml/x-5298235) (Ping timeout: 252 seconds)
2026-02-02 19:11:25 +0100ml|(~ml|@user/ml/x-5298235) ml|
2026-02-02 19:27:01 +0100ml|(~ml|@user/ml/x-5298235) (Ping timeout: 264 seconds)
2026-02-02 19:40:41 +0100ml|(~ml|@user/ml/x-5298235) ml|
2026-02-02 20:29:36 +0100attheo(~atta@120.sub-75-233-234.myvzw.com)
2026-02-02 20:37:20 +0100ChubaDuba(~ChubaDuba@109.195.234.244) ChubaDuba
2026-02-02 20:37:20 +0100Digitteknohippie(~user@user/digit) Digit
2026-02-02 20:37:46 +0100Digit(~user@user/digit) (Ping timeout: 256 seconds)
2026-02-02 20:50:32 +0100ml|(~ml|@user/ml/x-5298235) (Ping timeout: 240 seconds)
2026-02-02 21:01:10 +0100attheo(~atta@120.sub-75-233-234.myvzw.com) (Quit: leaving)
2026-02-02 21:04:13 +0100ml|(~ml|@user/ml/x-5298235) ml|
2026-02-02 22:27:04 +0100 <haskellbridge> <nemme> Heya
2026-02-02 22:27:04 +0100 <haskellbridge> ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/bJmhnSdYVFZpYDjjtmiFLZBe/qL_nwvBtQEg (3 lines)
2026-02-02 22:39:07 +0100 <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
2026-02-02 22:41:37 +0100 <haskellbridge> <geekosaur> liskin suggested (https://matrix.to/#/%21arvCkuMSDjUpxdkOoH%3Amatrix.org/%24CviURgZwDPgU4Cg0slJEH8nP4cvp5-t_1zIwhx0S…) smithay as an alternative starting point but I don't think anyone's taken him up on it yet
2026-02-02 22:43:45 +0100 <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
2026-02-02 22:44:37 +0100 <liskin> But I'll probably need to wait a few more months until I'm out of the worst bit of burnout
2026-02-02 22:44:47 +0100 <liskin> I have time, but not energy
2026-02-02 22:46:10 +0100 <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?)
2026-02-02 22:46:51 +0100 <haskellbridge> <geekosaur> central europe and asia look to be the real hotbeds to me
2026-02-02 22:48:47 +0100 <haskellbridge> <nemme> geekosaur: I'm glad that there are at least attempts
2026-02-02 22:49:42 +0100 <haskellbridge> <nemme> X11 just doesn't have low enough latency for me, so I was kinda forced to switch to wl
2026-02-02 22:50:07 +0100 <liskin> geekosaur: yeah that's my view as well - probably socioeconomic reasons or something
2026-02-02 22:51:47 +0100 <haskellbridge> <n​emme> I'll probably use niri for the time being, which also uses smithay instead of wl-roots
2026-02-02 22:52:27 +0100 <haskellbridge> <n​emme> +(with disabled animations)
2026-02-02 22:54:38 +0100 <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
2026-02-02 22:56:29 +0100 <haskellbridge> <n​emme> Hmm... would be an awesome project tho
2026-02-02 22:57:32 +0100 <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
2026-02-02 22:58:19 +0100 <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
2026-02-02 23:00:30 +0100 <haskellbridge> <n​emme> Well, maybe we should wait until pheonix (modern upgrade of X11) gets released
2026-02-02 23:01:06 +0100 <haskellbridge> <g​eekosaur> an alternative path forward there is wayland-x11, but I think it and xwayland still have shortcomings
2026-02-02 23:01:19 +0100 <haskellbridge> <g​eekosaur> that said, they seem to be being worked on
2026-02-02 23:03:51 +0100 <haskellbridge> <n​emme> * (https://git.dec05eba.com/phoenix/about/)
2026-02-02 23:04:42 +0100 <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
2026-02-02 23:06:50 +0100 <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
2026-02-02 23:07:34 +0100 <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_)
2026-02-02 23:09:47 +0100DigitteknohippieDigit
2026-02-02 23:11:02 +0100 <haskellbridge> <T​ranquil Ity> geekosaur: Why Smithay
2026-02-02 23:11:46 +0100 <haskellbridge> <g​eekosaur> I think just because it's not wlroots
2026-02-02 23:11:56 +0100 <haskellbridge> <g​eekosaur> and wlroots has been the death of every other attempt
2026-02-02 23:12:07 +0100 <haskellbridge> <T​ranquil Ity> geekosaur: What are the things missing from the existing protos?
2026-02-02 23:12:53 +0100 <haskellbridge> <T​ranquil Ity> geekosaur: Makes sense
2026-02-02 23:13:00 +0100 <haskellbridge> <g​eekosaur> "appName"/"className" is a big one (i.e. no useful "ManageHook"since titles are unreliable)
2026-02-02 23:13:36 +0100 <haskellbridge> <g​eekosaur> there's a limited version of "appName" that _some_ (not all) apps bother to set
2026-02-02 23:13:49 +0100 <haskellbridge> <g​eekosaur> "appName"/"className" is a big one (i.e. no useful "ManageHook" since titles are unreliable)
2026-02-02 23:14:17 +0100 <haskellbridge> <T​ranquil Ity> Titles are unreliable? Unsure I follow
2026-02-02 23:14:17 +0100 <haskellbridge> ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/hMQQhPAsBjCDztueNxqwmBHV/TDltYb22fuY (3 lines)
2026-02-02 23:14:30 +0100 <haskellbridge> <g​eekosaur> and I don't think wayland apps have an equivalent of "WM_WINDOW_ROLE" either
2026-02-02 23:15:01 +0100 <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
2026-02-02 23:16:06 +0100 <haskellbridge> <g​eekosaur> basically trying to control a window by title can get you into a game of whack-a-mole
2026-02-02 23:16:20 +0100 <haskellbridge> <g​eekosaur> +in your "ManageHook"
2026-02-02 23:17:30 +0100ChubaDuba(~ChubaDuba@109.195.234.244) (Quit: WeeChat 4.8.1)
2026-02-02 23:19:15 +0100 <haskellbridge> <T​ranquil Ity> geekosaur: Browser window titles _should_ be consistent (-ish, given it's a title)
2026-02-02 23:19:15 +0100 <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)
2026-02-02 23:20:48 +0100 <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
2026-02-02 23:21:02 +0100 <haskellbridge> <g​eekosaur> so the title at map time is something unusaful
2026-02-02 23:21:09 +0100 <haskellbridge> <g​eekosaur> * unusdful
2026-02-02 23:21:13 +0100 <haskellbridge> <g​eekosaur> * unuseful
2026-02-02 23:21:18 +0100 <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)
2026-02-02 23:21:21 +0100 <haskellbridge> I was skeptical of wlroots being a good idea before as well, to be clear, but with Smithay it's uh
2026-02-02 23:22:05 +0100 <haskellbridge> <T​ranquil Ity> geekosaur: You mean on X11?
2026-02-02 23:22:12 +0100 <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
2026-02-02 23:22:50 +0100 <haskellbridge> <T​ranquil Ity> Ah
2026-02-02 23:23:14 +0100 <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
2026-02-02 23:23:47 +0100 <haskellbridge> <T​ranquil Ity> Usually compositors don't show toplevels until they have a complete buffer attached
2026-02-02 23:24:21 +0100 <haskellbridge> <T​ranquil Ity> So, at least one full frame to show
2026-02-02 23:24:28 +0100 <haskellbridge> <T​ranquil Ity> Presumably by then the title has already been set
2026-02-02 23:24:46 +0100 <haskellbridge> <g​eekosaur> browsers require that buffer to be set up before they can run the JS that might draw in them
2026-02-02 23:25:39 +0100 <haskellbridge> <T​ranquil Ity> I don't follow how that relates
2026-02-02 23:26:07 +0100 <haskellbridge> <T​ranquil Ity> You alloc a buffer, draw to it, attach it
2026-02-02 23:26:08 +0100 <haskellbridge> (Or optionally send a syncobj to the compositor to wait on with the actual attaching)
2026-02-02 23:26:20 +0100 <haskellbridge> <T​ranquil Ity> The buffer must contain a finished frame
2026-02-02 23:28:22 +0100 <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
2026-02-02 23:35:15 +0100 <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
2026-02-02 23:35:58 +0100 <haskellbridge> <T​ranquil Ity> Unlike X11
2026-02-02 23:43:36 +0100 <haskellbridge> <g​eekosaur> that leads to users complaining the system isn't responsive
2026-02-02 23:43:51 +0100 <haskellbridge> <g​eekosaur> the browser has to do _something_ immediately
2026-02-02 23:52:20 +0100 <haskellbridge> <T​ranquil Ity> Have you tested it on WL?
2026-02-02 23:52:20 +0100 <haskellbridge> I'm curious, I should test if they just draw a buffer that's just a solid color and send that or smth
2026-02-02 23:53:44 +0100 <haskellbridge> <T​ranquil Ity> (To be clear, browsers have never been responsive to me)