Newest at the top
| 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 |
| 2026-02-02 23:03:51 +0100 | <haskellbridge> | <nemme> * (https://git.dec05eba.com/phoenix/about/) |
| 2026-02-02 23:01:19 +0100 | <haskellbridge> | <geekosaur> that said, they seem to be being worked on |
| 2026-02-02 23:01:06 +0100 | <haskellbridge> | <geekosaur> an alternative path forward there is wayland-x11, but I think it and xwayland still have shortcomings |
| 2026-02-02 23:00:30 +0100 | <haskellbridge> | <nemme> Well, maybe we should wait until pheonix (modern upgrade of X11) gets released |
| 2026-02-02 22:58:19 +0100 | <haskellbridge> | <geekosaur> 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 22:57:32 +0100 | <haskellbridge> | <geekosaur> 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:56:29 +0100 | <haskellbridge> | <nemme> Hmm... would be an awesome project tho |
| 2026-02-02 22:54:38 +0100 | <haskellbridge> | <geekosaur> 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:52:27 +0100 | <haskellbridge> | <nemme> +(with disabled animations) |
| 2026-02-02 22:51:47 +0100 | <haskellbridge> | <nemme> I'll probably use niri for the time being, which also uses smithay instead of wl-roots |