Newest at the top
| 2026-02-03 00:04:53 +0100 | <haskellbridge> | <geekosaur> (see also: electron apps) |
| 2026-02-03 00:03:48 +0100 | <haskellbridge> | <geekosaur> (and let's face it, anything that complex written mostly in JS is going to have sucky responsiveness…) |
| 2026-02-03 00:03:21 +0100 | <haskellbridge> | <geekosaur> that's the problem. they'd look even less responsive if double-buffered |
| 2026-02-02 23:53:44 +0100 | <haskellbridge> | <Tranquil Ity> (To be clear, browsers have never been responsive to me) |
| 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:52:20 +0100 | <haskellbridge> | <Tranquil Ity> Have you tested it on WL? |
| 2026-02-02 23:43:51 +0100 | <haskellbridge> | <geekosaur> the browser has to do _something_ immediately |
| 2026-02-02 23:43:36 +0100 | <haskellbridge> | <geekosaur> that leads to users complaining the system isn't responsive |
| 2026-02-02 23:35:58 +0100 | <haskellbridge> | <Tranquil Ity> Unlike X11 |
| 2026-02-02 23:35:15 +0100 | <haskellbridge> | <Tranquil 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:28:22 +0100 | <haskellbridge> | <Tranquil 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:26:20 +0100 | <haskellbridge> | <Tranquil Ity> The buffer must contain a finished frame |
| 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:07 +0100 | <haskellbridge> | <Tranquil Ity> You alloc a buffer, draw to it, attach it |
| 2026-02-02 23:25:39 +0100 | <haskellbridge> | <Tranquil Ity> I don't follow how that relates |
| 2026-02-02 23:24:46 +0100 | <haskellbridge> | <geekosaur> browsers require that buffer to be set up before they can run the JS that might draw in them |
| 2026-02-02 23:24:28 +0100 | <haskellbridge> | <Tranquil Ity> Presumably by then the title has already been set |
| 2026-02-02 23:24:21 +0100 | <haskellbridge> | <Tranquil Ity> So, at least one full frame to show |
| 2026-02-02 23:23:47 +0100 | <haskellbridge> | <Tranquil Ity> Usually compositors don't show toplevels until they have a complete buffer attached |
| 2026-02-02 23:23:14 +0100 | <haskellbridge> | <geekosaur> 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:22:50 +0100 | <haskellbridge> | <Tranquil Ity> Ah |
| 2026-02-02 23:22:12 +0100 | <haskellbridge> | <geekosaur> 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:05 +0100 | <haskellbridge> | <Tranquil Ity> geekosaur: You mean on X11? |
| 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:21:18 +0100 | <haskellbridge> | <Tranquil 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:13 +0100 | <haskellbridge> | <geekosaur> * unuseful |
| 2026-02-02 23:21:09 +0100 | <haskellbridge> | <geekosaur> * unusdful |
| 2026-02-02 23:21:02 +0100 | <haskellbridge> | <geekosaur> so the title at map time is something unusaful |
| 2026-02-02 23:20:48 +0100 | <haskellbridge> | <geekosaur> 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: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:19:15 +0100 | <haskellbridge> | <Tranquil Ity> geekosaur: Browser window titles _should_ be consistent (-ish, given it's a title) |
| 2026-02-02 23:17:30 +0100 | ChubaDuba | (~ChubaDuba@109.195.234.244) (Quit: WeeChat 4.8.1) |
| 2026-02-02 23:16:20 +0100 | <haskellbridge> | <geekosaur> +in your "ManageHook" |
| 2026-02-02 23:16:06 +0100 | <haskellbridge> | <geekosaur> basically trying to control a window by title can get you into a game of whack-a-mole |
| 2026-02-02 23:15:01 +0100 | <haskellbridge> | <geekosaur> 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:14:30 +0100 | <haskellbridge> | <geekosaur> and I don't think wayland apps have an equivalent of "WM_WINDOW_ROLE" either |
| 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:17 +0100 | <haskellbridge> | <Tranquil Ity> Titles are unreliable? Unsure I follow |
| 2026-02-02 23:13:49 +0100 | <haskellbridge> | <geekosaur> "appName"/"className" is a big one (i.e. no useful "ManageHook" since titles are unreliable) |
| 2026-02-02 23:13:36 +0100 | <haskellbridge> | <geekosaur> there's a limited version of "appName" that _some_ (not all) apps bother to set |
| 2026-02-02 23:13:00 +0100 | <haskellbridge> | <geekosaur> "appName"/"className" is a big one (i.e. no useful "ManageHook"since titles are unreliable) |
| 2026-02-02 23:12:53 +0100 | <haskellbridge> | <Tranquil Ity> geekosaur: Makes sense |
| 2026-02-02 23:12:07 +0100 | <haskellbridge> | <Tranquil Ity> geekosaur: What are the things missing from the existing protos? |
| 2026-02-02 23:11:56 +0100 | <haskellbridge> | <geekosaur> and wlroots has been the death of every other attempt |
| 2026-02-02 23:11:46 +0100 | <haskellbridge> | <geekosaur> I think just because it's not wlroots |
| 2026-02-02 23:11:02 +0100 | <haskellbridge> | <Tranquil Ity> geekosaur: Why Smithay |
| 2026-02-02 23:09:47 +0100 | Digitteknohippie | Digit |
| 2026-02-02 23:07:34 +0100 | <haskellbridge> | <geekosaur> (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:06:50 +0100 | <haskellbridge> | <geekosaur> 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:04:42 +0100 | <haskellbridge> | <geekosaur> 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 |