Newest at the top
| 2026-02-03 01:22:19 +0100 | <haskellbridge> | <geekosaur> I think any such separation for xmonad would require a non-wayland private IPC connection |
| 2026-02-03 01:20:15 +0100 | <haskellbridge> | <geekosaur> as to our requirements list, I think the best we'd do is go through the open issues (here and possibly on the old google issues, which is still there but read only) and collect and probably tag them |
| 2026-02-03 01:19:29 +0100 | <haskellbridge> | <geekosaur> liskin: someone actually proposed separating them in general and a protocol for doing so. it was soundly thrashed for security reasons iirc |
| 2026-02-03 01:13:06 +0100 | <liskin> | Anyway, bedtime now. |
| 2026-02-03 01:11:57 +0100 | <liskin> | (I have some extra bits in place so even if I screw up and it crashes or goes into a loop, I can still recover - like dumping the state to tmpfs every minute and systemd auto-restarts) |
| 2026-02-03 01:10:10 +0100 | <liskin> | I wonder how people develop their Wayland compositors. I've always worked on the same xmonad that was running my main session. That kind of quick feedback loop is extremely valuable IMO |
| 2026-02-03 01:08:44 +0100 | <liskin> | My main motivations for the separation of compositor and wm was: latency (no Haskell garbage collection), and ease of development - being able to restart the wm without losing the session, like you can in X11 |
| 2026-02-03 01:06:01 +0100 | <liskin> | Would be nice to have a wiki page with these "requirements". |
| 2026-02-03 01:05:45 +0100 | <liskin> | Anyway, geekosaur, do we perhaps have a list of "things people expect from xmonad"? I certainly have an idea of what I expect from it, but I guess other people have very different needs. |
| 2026-02-03 01:04:39 +0100 | <liskin> | Compositor in Rust/C, talking to the Haskell window manager over some IPC. Could be Wayland protocol, could be whatever else |
| 2026-02-03 01:04:03 +0100 | <liskin> | But then my idea has always (a couple years) been to have a separate compositor and window manager. |
| 2026-02-03 01:03:33 +0100 | <liskin> | Actually I specifically preferred Smithay because of Rust. |
| 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 |