| 2026-02-03 00:03:21 +0100 | <haskellbridge> | <geekosaur> that's the problem. they'd look even less responsive if double-buffered |
| 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:04:53 +0100 | <haskellbridge> | <geekosaur> (see also: electron apps) |
| 2026-02-03 01:03:33 +0100 | <liskin> | Actually I specifically preferred Smithay because of Rust. |
| 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: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: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:06:01 +0100 | <liskin> | Would be nice to have a wiki page with these "requirements". |
| 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: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: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:13:06 +0100 | <liskin> | Anyway, bedtime now. |
| 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: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:22:19 +0100 | <haskellbridge> | <geekosaur> I think any such separation for xmonad would require a non-wayland private IPC connection |
| 2026-02-03 02:14:22 +0100 | Digit | (~user@user/digit) (Ping timeout: 246 seconds) |
| 2026-02-03 02:26:50 +0100 | <haskellbridge> | <Tranquil Ity> liskin: That makes sense |
| 2026-02-03 02:26:50 +0100 | <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 02:27:09 +0100 | <haskellbridge> | <Tranquil Ity> liskin: Embedded Wayland window within another Wayland compositor is the usual way |
| 2026-02-03 02:27:23 +0100 | <haskellbridge> | <Tranquil Ity> Or a separate VT |
| 2026-02-03 02:27:36 +0100 | <haskellbridge> | <Tranquil Ity> At least that's how I did it (both of these) |
| 2026-02-03 02:27:42 +0100 | <haskellbridge> | <Tranquil Ity> * do |
| 2026-02-03 02:47:50 +0100 | Digit | (~user@user/digit) Digit |
| 2026-02-03 07:40:38 +0100 | <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 07:40:58 +0100 | <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 07:41:00 +0100 | <haskellbridge> | edit: i have no position of authority on the matter - purely vibe |
| 2026-02-03 07:43:18 +0100 | ChubaDuba | (~ChubaDuba@37.112.231.64) ChubaDuba |
| 2026-02-03 08:02:58 +0100 | <geekosaur> | there's a few similarities but enough differences that it doesn't make a good mapping |
| 2026-02-03 08:14:47 +0100 | ft | (~ft@p508db4c0.dip0.t-ipconnect.de) (Quit: leaving) |
| 2026-02-03 09:27:11 +0100 | Enrico63 | (~Enrico63@148.252.128.12) Enrico63 |
| 2026-02-03 10:48:43 +0100 | ChubaDuba | (~ChubaDuba@37.112.231.64) (Quit: WeeChat 4.8.1) |
| 2026-02-03 10:49:01 +0100 | ChubaDuba | (~ChubaDuba@37.112.231.64) ChubaDuba |
| 2026-02-03 10:55:14 +0100 | ChubaDuba | (~ChubaDuba@37.112.231.64) (Quit: WeeChat 4.8.1) |
| 2026-02-03 10:55:33 +0100 | ChubaDuba | (~ChubaDuba@37.112.231.64) ChubaDuba |
| 2026-02-03 11:13:32 +0100 | ChubaDuba | (~ChubaDuba@37.112.231.64) (Quit: WeeChat 4.8.1) |
| 2026-02-03 11:14:08 +0100 | <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 11:14:11 +0100 | ChubaDuba | (~ChubaDuba@37.112.231.64) ChubaDuba |
| 2026-02-03 11:14:58 +0100 | <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 11:16:20 +0100 | <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 11:17:37 +0100 | <liskin> | (Note the subtle difference between "protocol" and "channel") |
| 2026-02-03 11:19:27 +0100 | ChubaDuba | (~ChubaDuba@37.112.231.64) (Quit: WeeChat 4.8.1) |
| 2026-02-03 11:20:26 +0100 | ChubaDuba | (~ChubaDuba@37.112.231.64) ChubaDuba |
| 2026-02-03 11:38:43 +0100 | <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 11:46:40 +0100 | Enrico63 | (~Enrico63@148.252.128.12) (Quit: Client closed) |
| 2026-02-03 11:56:11 +0100 | Enrico63 | (~Enrico63@148.252.128.12) Enrico63 |
| 2026-02-03 12:30:31 +0100 | redgloboli | (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2026-02-03 12:32:15 +0100 | redgloboli | (~redglobol@user/redgloboli) redgloboli |
| 2026-02-03 13:59:38 +0100 | Enrico63 | (~Enrico63@148.252.128.12) (Quit: Client closed) |
| 2026-02-03 15:38:28 +0100 | Enrico63 | (~Enrico63@148.252.128.12) Enrico63 |
| 2026-02-03 16:20:25 +0100 | Digit | (~user@user/digit) (Ping timeout: 264 seconds) |
| 2026-02-03 16:26:32 +0100 | Digit | (~user@user/digit) Digit |
| 2026-02-03 16:27:17 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2026-02-03 16:28:16 +0100 | <geekosaur> | yeh, not sure what happened with that |
| 2026-02-03 16:43:20 +0100 | Digit | (~user@user/digit) (Remote host closed the connection) |
| 2026-02-03 16:43:31 +0100 | Digitteknohippie | (~user@user/digit) (Quit: ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.2)) |
| 2026-02-03 16:47:16 +0100 | Digit | (~user@user/digit) Digit |
| 2026-02-03 17:02:45 +0100 | T_X | (~T_X@diktynna.open-mesh.org) (Read error: Connection reset by peer) |
| 2026-02-03 17:03:24 +0100 | T_X | (~T_X@diktynna.open-mesh.org) T_X |
| 2026-02-03 18:51:41 +0100 | Enrico63 | (~Enrico63@148.252.128.12) (Quit: Client closed) |
| 2026-02-03 19:00:16 +0100 | ft | (~ft@p508db4c0.dip0.t-ipconnect.de) ft |
| 2026-02-03 19:16:33 +0100 | Enrico63 | (~Enrico63@148.252.128.12) Enrico63 |
| 2026-02-03 19:50:15 +0100 | Enrico63 | (~Enrico63@148.252.128.12) (Quit: Client closed) |
| 2026-02-03 20:11:35 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2026-02-03 20:12:55 +0100 | Digit | (~user@user/digit) (Ping timeout: 240 seconds) |
| 2026-02-03 21:10:23 +0100 | Digitteknohippie | Digit |
| 2026-02-03 23:11:17 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2026-02-03 23:11:29 +0100 | Digit | (~user@user/digit) (Ping timeout: 260 seconds) |
| 2026-02-03 23:32:59 +0100 | Digitteknohippie | Digit |