Logs: liberachat/#xmonad
| 2026-02-02 21:52:27 | <haskellbridge> | <nemme> +(with disabled animations) |
| 2026-02-02 21:54:38 | <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 21:56:29 | <haskellbridge> | <nemme> Hmm... would be an awesome project tho |
| 2026-02-02 21:57:32 | <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 21:58:19 | <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:00:30 | <haskellbridge> | <nemme> Well, maybe we should wait until pheonix (modern upgrade of X11) gets released |
| 2026-02-02 22:01:06 | <haskellbridge> | <geekosaur> an alternative path forward there is wayland-x11, but I think it and xwayland still have shortcomings |
| 2026-02-02 22:01:19 | <haskellbridge> | <geekosaur> that said, they seem to be being worked on |
| 2026-02-02 22:03:51 | <haskellbridge> | <nemme> * (https://git.dec05eba.com/phoenix/about/) |
| 2026-02-02 22:04:42 | <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 22:06:50 | <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 22:07:34 | <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 22:09:47 | Digitteknohippie | is now known as Digit |
| 2026-02-02 22:11:02 | <haskellbridge> | <Tranquil Ity> geekosaur: Why Smithay |
| 2026-02-02 22:11:46 | <haskellbridge> | <geekosaur> I think just because it's not wlroots |
| 2026-02-02 22:11:56 | <haskellbridge> | <geekosaur> and wlroots has been the death of every other attempt |
| 2026-02-02 22:12:07 | <haskellbridge> | <Tranquil Ity> geekosaur: What are the things missing from the existing protos? |
| 2026-02-02 22:12:53 | <haskellbridge> | <Tranquil Ity> geekosaur: Makes sense |
| 2026-02-02 22:13:00 | <haskellbridge> | <geekosaur> "appName"/"className" is a big one (i.e. no useful "ManageHook"since titles are unreliable) |
| 2026-02-02 22:13:36 | <haskellbridge> | <geekosaur> there's a limited version of "appName" that _some_ (not all) apps bother to set |
| 2026-02-02 22:13:49 | <haskellbridge> | <geekosaur> "appName"/"className" is a big one (i.e. no useful "ManageHook" since titles are unreliable) |
| 2026-02-02 22:14:17 | <haskellbridge> | <Tranquil Ity> Titles are unreliable? Unsure I follow |
| 2026-02-02 22:14:17 | <haskellbridge> | ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/hMQQhPAsBjCDztueNxqwmBHV/TDltYb22fuY (3 lines) |
| 2026-02-02 22:14:30 | <haskellbridge> | <geekosaur> and I don't think wayland apps have an equivalent of "WM_WINDOW_ROLE" either |
| 2026-02-02 22:15:01 | <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 22:16:06 | <haskellbridge> | <geekosaur> basically trying to control a window by title can get you into a game of whack-a-mole |
| 2026-02-02 22:16:20 | <haskellbridge> | <geekosaur> +in your "ManageHook" |
| 2026-02-02 22:17:30 | × | ChubaDuba quits (~ChubaDuba@109.195.234.244) (Quit: WeeChat 4.8.1) |
| 2026-02-02 22:19:15 | <haskellbridge> | <Tranquil Ity> geekosaur: Browser window titles _should_ be consistent (-ish, given it's a title) |
| 2026-02-02 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) |
| 2026-02-02 22:20:48 | <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 22:21:02 | <haskellbridge> | <geekosaur> so the title at map time is something unusaful |
| 2026-02-02 22:21:09 | <haskellbridge> | <geekosaur> * unusdful |
| 2026-02-02 22:21:13 | <haskellbridge> | <geekosaur> * unuseful |
| 2026-02-02 22:21:18 | <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 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 |
| 2026-02-02 22:22:05 | <haskellbridge> | <Tranquil Ity> geekosaur: You mean on X11? |
| 2026-02-02 22:22:12 | <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 22:22:50 | <haskellbridge> | <Tranquil Ity> Ah |
| 2026-02-02 22:23:14 | <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 22:23:47 | <haskellbridge> | <Tranquil Ity> Usually compositors don't show toplevels until they have a complete buffer attached |
| 2026-02-02 22:24:21 | <haskellbridge> | <Tranquil Ity> So, at least one full frame to show |
| 2026-02-02 22:24:28 | <haskellbridge> | <Tranquil Ity> Presumably by then the title has already been set |
| 2026-02-02 22:24:46 | <haskellbridge> | <geekosaur> browsers require that buffer to be set up before they can run the JS that might draw in them |
| 2026-02-02 22:25:39 | <haskellbridge> | <Tranquil Ity> I don't follow how that relates |
| 2026-02-02 22:26:07 | <haskellbridge> | <Tranquil Ity> You alloc a buffer, draw to it, attach it |
| 2026-02-02 22:26:08 | <haskellbridge> | (Or optionally send a syncobj to the compositor to wait on with the actual attaching) |
| 2026-02-02 22:26:20 | <haskellbridge> | <Tranquil Ity> The buffer must contain a finished frame |
| 2026-02-02 22:28:22 | <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 22:35:15 | <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 22:35:58 | <haskellbridge> | <Tranquil Ity> Unlike X11 |
| 2026-02-02 22:43:36 | <haskellbridge> | <geekosaur> that leads to users complaining the system isn't responsive |
| 2026-02-02 22:43:51 | <haskellbridge> | <geekosaur> the browser has to do _something_ immediately |
| 2026-02-02 22:52:20 | <haskellbridge> | <Tranquil Ity> Have you tested it on WL? |
| 2026-02-02 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 |
| 2026-02-02 22:53:44 | <haskellbridge> | <Tranquil Ity> (To be clear, browsers have never been responsive to me) |
| 2026-02-02 23:03:21 | <haskellbridge> | <geekosaur> that's the problem. they'd look even less responsive if double-buffered |
| 2026-02-02 23:03:48 | <haskellbridge> | <geekosaur> (and let's face it, anything that complex written mostly in JS is going to have sucky responsiveness…) |
| 2026-02-02 23:04:53 | <haskellbridge> | <geekosaur> (see also: electron apps) |
| 2026-02-03 00:03:33 | <liskin> | Actually I specifically preferred Smithay because of Rust. |
| 2026-02-03 00:04:03 | <liskin> | But then my idea has always (a couple years) been to have a separate compositor and window manager. |
| 2026-02-03 00:04:39 | <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 00:05:45 | <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 00:06:01 | <liskin> | Would be nice to have a wiki page with these "requirements". |
| 2026-02-03 00:08:44 | <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 00:10:10 | <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 00:11:57 | <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 00:13:06 | <liskin> | Anyway, bedtime now. |
| 2026-02-03 00:19:29 | <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 00:20:15 | <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 00:22:19 | <haskellbridge> | <geekosaur> I think any such separation for xmonad would require a non-wayland private IPC connection |
| 2026-02-03 01:14:22 | × | Digit quits (~user@user/digit) (Ping timeout: 246 seconds) |
| 2026-02-03 01:26:50 | <haskellbridge> | <Tranquil Ity> liskin: That makes sense |
| 2026-02-03 01:26:50 | <haskellbridge> | If you wanna adapt the reference Smithay compositor for that I can maybe help out, it should serve as a good base despite them wanting to drop it. |
| 2026-02-03 01:27:09 | <haskellbridge> | <Tranquil Ity> liskin: Embedded Wayland window within another Wayland compositor is the usual way |
| 2026-02-03 01:27:23 | <haskellbridge> | <Tranquil Ity> Or a separate VT |
| 2026-02-03 01:27:36 | <haskellbridge> | <Tranquil Ity> At least that's how I did it (both of these) |
| 2026-02-03 01:27:42 | <haskellbridge> | <Tranquil Ity> * do |
| 2026-02-03 01:47:50 | → | Digit joins (~user@user/digit) |
| 2026-02-03 06:40:38 | <haskellbridge> | <dpn> Tranquil Ity: i haven't thought much about rust <> haskell - but I've mentally always kinda thought traits were somewhat comparable to hs classes :think |
| 2026-02-03 06:40:58 | <haskellbridge> | <dpn> i haven't thought much about rust <> haskell - but I've mentally always kinda thought traits were somewhat comparable to hs classes 🤔 |
| 2026-02-03 06:41:00 | <haskellbridge> | edit: i have no position of authority on the matter - purely vibe |
| 2026-02-03 06:43:18 | → | ChubaDuba joins (~ChubaDuba@37.112.231.64) |
| 2026-02-03 07:02:58 | <geekosaur> | there's a few similarities but enough differences that it doesn't make a good mapping |
| 2026-02-03 07:14:47 | × | ft quits (~ft@p508db4c0.dip0.t-ipconnect.de) (Quit: leaving) |
| 2026-02-03 08:27:11 | → | Enrico63 joins (~Enrico63@148.252.128.12) |
| 2026-02-03 09:48:43 | × | ChubaDuba quits (~ChubaDuba@37.112.231.64) (Quit: WeeChat 4.8.1) |
| 2026-02-03 09:49:01 | → | ChubaDuba joins (~ChubaDuba@37.112.231.64) |
| 2026-02-03 09:55:14 | × | ChubaDuba quits (~ChubaDuba@37.112.231.64) (Quit: WeeChat 4.8.1) |
| 2026-02-03 09:55:33 | → | ChubaDuba joins (~ChubaDuba@37.112.231.64) |
| 2026-02-03 10:13:32 | × | ChubaDuba quits (~ChubaDuba@37.112.231.64) (Quit: WeeChat 4.8.1) |
| 2026-02-03 10:14:08 | <liskin> | Security reasons my ass. That's like saying postfix or qmail is less secure than sendmail because they separate functionality into smaller processes. |
| 2026-02-03 10:14:11 | → | ChubaDuba joins (~ChubaDuba@37.112.231.64) |
| 2026-02-03 10:14:58 | <liskin> | Sure, doing it the same way as X11 would be insecure. Having a privileged wm communicating over a secure channel is fine. |
| 2026-02-03 10:16:20 | <liskin> | Speaking of that channel - I considered Wayland protocol because I suspected we might need to send some Wayland data structures from the compositor to the WM, and it might just be easier to do over the same protocol. Unless implementing it on the Haskell side is a major pain in the ass. |
| 2026-02-03 10:17:37 | <liskin> | (Note the subtle difference between "protocol" and "channel") |
| 2026-02-03 10:19:27 | × | ChubaDuba quits (~ChubaDuba@37.112.231.64) (Quit: WeeChat 4.8.1) |
| 2026-02-03 10:20:26 | → | ChubaDuba joins (~ChubaDuba@37.112.231.64) |
| 2026-02-03 10:38:43 | <liskin> | I think there's also an issue in our tracker where someone's trying to introduce a PureLayout class or something so they can run the layout algorithms as a plugin for some existing Wayland compositor. That's something I'd love to learn more about maybe :-) |
| 2026-02-03 10:46:40 | × | Enrico63 quits (~Enrico63@148.252.128.12) (Quit: Client closed) |
All times are in UTC.