Logs: liberachat/#xmonad
| 2025-10-23 18:03:23 | <geekosaur> | there's an alternative EWMH fullscreen implementation using a layout, which should advertise properly |
| 2025-10-23 18:04:00 | <geekosaur> | https://hackage.haskell.org/package/xmonad-contrib-0.18.1/docs/XMonad-Layout-Fullscreen.html |
| 2025-10-23 18:04:11 | <L29Ah> | also i don't remember problems with mplayer but maybe my memory is rotting away as mplayer was removed from my system over 12 years ago |
| 2025-10-23 18:04:47 | → | ft joins (~ft@p4fc2aaeb.dip0.t-ipconnect.de) |
| 2025-10-23 18:05:29 | <Enrico63> | Oh, ok, sorry, I forgot what my initial point was: I wanted to tell whether a program is full-screen, and Full+mplayer tiled-and-focused doesn't result in xprop reporting FULLSCREEN. |
| 2025-10-23 18:25:05 | <Enrico63> | geekosaur, how is that module supposed to work? As soon as I set ` handleEventHook = fullscreenEventHook, manageHook = fullscreenManageHook` and recompile, I do see differences, .e.g when I open mplayer, it opens as tiled, and _its_ `f` command doesn't have any effect on the layout (even though `xprop` reveleas whether mplayer thinks to be in |
| 2025-10-23 18:25:06 | <Enrico63> | fullscreen). |
| 2025-10-23 18:27:46 | <geekosaur> | That sounds wrong, it should be sending an EWMH event which both changes the property and fullscreens the window |
| 2025-10-23 18:28:26 | <geekosaur> | But I can't check right now, I'll be away from my desk for about half an hour |
| 2025-10-23 18:28:39 | <Enrico63> | For that, am I supposed to actually use one of the functions, e.g. `fullscreenFull`? |
| 2025-10-23 18:28:47 | <Enrico63> | Ok, ok, NP. |
| 2025-10-23 18:29:05 | <geekosaur> | No, the event should do it |
| 2025-10-23 18:29:56 | <geekosaur> | The functions are for doing it via xmonad commands and to implement the events |
| 2025-10-23 18:44:30 | <Enrico63> | Just tried with `mpv` instead of `mplayer`. Even without setting `handleEventHook = XMonad.Layout.Fullscreen.fullscreenEventHook, manageHook = XMonad.Layout.Fullscreen.fullscreenManageHook`, it starts in tiled mode, in which case `xprop | grep FULLSCREEN` correctly gives no match, and upon pressing `f` it goes fullscreen (also correctly covering |
| 2025-10-23 18:44:31 | <Enrico63> | xmobar without me needing to mod+b to hide it) and `xprop | grep FULLSCREEN` does give a match. |
| 2025-10-23 18:45:06 | <Enrico63> | I suppose I can just throw away `mplayer` and embrace `mpv`. |
| 2025-10-23 18:59:59 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-10-23 19:05:21 | → | Enrico63 joins (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) |
| 2025-10-23 19:27:29 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-10-23 19:32:24 | → | Enrico63 joins (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) |
| 2025-10-23 19:34:42 | → | Digitteknohippie joins (~user@user/digit) |
| 2025-10-23 19:41:36 | × | rekahsoft quits (~rekahsoft@70.51.99.245) (*.net *.split) |
| 2025-10-23 19:41:36 | × | Digit quits (~user@user/digit) (*.net *.split) |
| 2025-10-23 19:41:36 | × | ml| quits (~ml|@user/ml/x-5298235) (*.net *.split) |
| 2025-10-23 19:48:52 | → | ml| joins (~ml|@user/ml/x-5298235) |
| 2025-10-23 19:49:50 | Digitteknohippie | is now known as Digit |
| 2025-10-23 21:59:00 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-10-24 02:04:47 | × | amenonsen quits (~amenonsen@pitta.toroid.org) (Remote host closed the connection) |
| 2025-10-24 02:18:12 | → | amenonsen joins (~amenonsen@pitta.toroid.org) |
| 2025-10-24 02:28:52 | × | td_ quits (~td@i53870926.versanet.de) (Ping timeout: 260 seconds) |
| 2025-10-24 02:35:14 | → | td_ joins (~td@2001:9e8:19e0:2a00:334f:6dc4:3cb7:9653) |
| 2025-10-24 04:27:35 | → | ChubaDuba joins (~ChubaDuba@5.166.232.68) |
| 2025-10-24 04:28:48 | × | ChubaDuba quits (~ChubaDuba@5.166.232.68) (Client Quit) |
| 2025-10-24 05:01:15 | → | Lears joins (~Leary@user/Leary/x-0910699) |
| 2025-10-24 05:01:54 | × | Leary quits (~Leary@user/Leary/x-0910699) (Ping timeout: 256 seconds) |
| 2025-10-24 05:02:56 | Lears | is now known as Leary |
| 2025-10-24 05:14:40 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-10-24 05:39:22 | → | Enrico63 joins (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) |
| 2025-10-24 06:23:01 | × | ft quits (~ft@p4fc2aaeb.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-10-24 06:29:28 | <Enrico63> | Leary, I ended up trying mpv. Thanks for the suggestion! |
| 2025-10-24 06:33:39 | <Leary> | Enrico63: You got the wrong guy, though I do second it. |
| 2025-10-24 06:34:23 | <Enrico63> | Oh, yeah, sorry, it was @L29Ah |
| 2025-10-24 06:44:51 | <Enrico63> | Anyway, can anybody help me choose a session lock? Not that it matters much, I'm not gonna leave my laptop unattended very often (and that's why I haven't used it for long, the laptop is always locked in my room). On https://wiki.archlinux.org/title/Session_lock I see several listed, but then if I go look at each of them, I'm not sure how to |
| 2025-10-24 06:44:52 | <Enrico63> | decide. For instance: `xsecurelock` claims to be more secure than others (at least that's how I interpret the readme), but the last commit on github is 2 years ago, whereas xss-lock has commits from last month, but hasn't got such claims about security. |
| 2025-10-24 07:21:34 | <deebo> | what i've done for years is just use a gnome2 fork and replace the window manager with xmonad, previously for example xfce but for quite a few years now mate |
| 2025-10-24 07:37:28 | → | yecinem_ joins (~yecinem@p200300ee0f0876008e234cd803b8a022.dip0.t-ipconnect.de) |
| 2025-10-24 07:59:45 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-10-24 08:06:43 | → | Enrico63 joins (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) |
| 2025-10-24 08:56:50 | <haskellbridge> | <Solid> Enrico63: Nothing better than (even from a security perspective, AFAIK) than goold old xscreensaver :) |
| 2025-10-24 09:47:50 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-10-24 09:57:42 | → | xjcj joins (~xjcj@dslb-002-201-020-196.002.201.pools.vodafone-ip.de) |
| 2025-10-24 10:00:45 | → | sajenim joins (~sajenim@user/sajenim) |
| 2025-10-24 10:00:47 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 2025-10-24 10:04:40 | × | xjcj quits (~xjcj@dslb-002-201-020-196.002.201.pools.vodafone-ip.de) (Quit: Client closed) |
| 2025-10-24 10:04:58 | → | xjcj joins (~xjcj@dslb-002-201-020-196.002.201.pools.vodafone-ip.de) |
| 2025-10-24 10:07:37 | → | xjcj1 joins (~xjcj@dynamic-176-001-198-020.176.1.pool.telefonica.de) |
| 2025-10-24 10:10:19 | × | xjcj quits (~xjcj@dslb-002-201-020-196.002.201.pools.vodafone-ip.de) (Ping timeout: 250 seconds) |
| 2025-10-24 10:10:46 | × | xjcj1 quits (~xjcj@dynamic-176-001-198-020.176.1.pool.telefonica.de) (Client Quit) |
| 2025-10-24 10:12:24 | → | Enrico63 joins (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) |
| 2025-10-24 10:12:25 | → | xjcj joins (~xjcj@dslb-084-061-254-103.084.061.pools.vodafone-ip.de) |
| 2025-10-24 10:13:09 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Client Quit) |
| 2025-10-24 10:21:32 | → | xjcj8 joins (~xjcj@dynamic-176-001-198-020.176.1.pool.telefonica.de) |
| 2025-10-24 10:21:33 | × | xjcj quits (~xjcj@dslb-084-061-254-103.084.061.pools.vodafone-ip.de) (Quit: Client closed) |
| 2025-10-24 10:22:02 | × | xjcj8 quits (~xjcj@dynamic-176-001-198-020.176.1.pool.telefonica.de) (Client Quit) |
| 2025-10-24 10:22:19 | → | xjcj joins (~xjcj@dslb-084-061-254-103.084.061.pools.vodafone-ip.de) |
| 2025-10-24 10:32:25 | × | xjcj quits (~xjcj@dslb-084-061-254-103.084.061.pools.vodafone-ip.de) (Ping timeout: 250 seconds) |
| 2025-10-24 10:36:36 | → | Enrico63 joins (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) |
| 2025-10-24 10:48:41 | → | xjcj joins (~xjcj@dslb-084-061-254-103.084.061.pools.vodafone-ip.de) |
| 2025-10-24 10:55:07 | × | xjcj quits (~xjcj@dslb-084-061-254-103.084.061.pools.vodafone-ip.de) (Quit: Client closed) |
| 2025-10-24 11:13:24 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-10-24 11:53:26 | → | Enrico63 joins (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) |
| 2025-10-24 13:13:18 | → | ft joins (~ft@p4fc2aaeb.dip0.t-ipconnect.de) |
| 2025-10-24 14:59:47 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-10-24 15:15:06 | × | MrElendig quits (~Urist@archlinux/op/MrElendig) (Quit: hail hydra) |
| 2025-10-24 15:16:00 | → | MrElendig joins (~Urist@archlinux/op/MrElendig) |
| 2025-10-24 15:16:05 | <liskin> | geekosaur: is wayback reputable enough? |
| 2025-10-24 15:18:03 | <liskin> | Enrico63 seems to have left and I don't remember how to ask lambdabot, so I'll just ramble into the void: xss-lock and xsecurelock work together, and xscreensaver is an alternative that replaces both |
| 2025-10-24 15:18:43 | <geekosaur> | I think the problem there is that, while Wayland has the potential to fix several X11 problems such as different screen resolutions working together properly, it doesn't actually do so. that said, if you're implementing X11 APIs on top of it you wouldn't be able to take advantage even if your Wayland impl did it properly |
| 2025-10-24 15:18:59 | <geekosaur> | it's "!ask" or "!tell" |
| 2025-10-24 15:19:10 | <geekosaur> | er, @ or ? in place of ! |
| 2025-10-24 15:19:14 | <geekosaur> | wrong bot 🙂 |
| 2025-10-24 15:19:32 | <geekosaur> | (I use the one in #crawl more often these days 🙂 ) |
| 2025-10-24 15:20:21 | <liskin> | xscreensaver used to be insecure because too much stuff was in the same process and a crash would unlock the screen, jwz has since fixed it |
| 2025-10-24 15:20:50 | <geekosaur> | xlock / xautolock is another combo intended to work together |
| 2025-10-24 15:21:01 | <liskin> | geekosaur: my response is to your question about reputable X11 fork |
| 2025-10-24 15:21:08 | <geekosaur> | but xlock still has the everything-in-one-process issue |
| 2025-10-24 15:21:20 | <liskin> | Unless you wanted that fork to solve the resolution problem |
| 2025-10-24 15:21:33 | <geekosaur> | liskin, it's not a fork, it's an implementation of X11 APIs on top of a Wayland backend |
| 2025-10-24 15:21:50 | <geekosaur> | "experimental X11 compatibility layer" |
| 2025-10-24 15:22:10 | <liskin> | Which is... fine? Xwayland is maintained, and wayback is maintained. What's missing. |
| 2025-10-24 15:23:30 | <geekosaur> | the topic was forking Xorg specifically |
| 2025-10-24 15:23:48 | <geekosaur> | which would be less experimental than trying to rebuild X11 on top of Wayland |
| 2025-10-24 15:24:09 | <liskin> | But they're not rebuilding it. |
| 2025-10-24 15:24:19 | <liskin> | It's just a rootful Xwayland |
| 2025-10-24 15:24:47 | <liskin> | A little bit of glue code between well maintained components such as Xwayland |
| 2025-10-24 15:25:20 | <liskin> | Exactly what I said we could do as an interim solution in like 2021 or something |
| 2025-10-24 15:25:53 | <liskin> | They just beat me to it (not that I was going to race them or anything - xserver works just fine for me) |
| 2025-10-24 15:30:57 | <geekosaur> | Also I'm a bit skittish about it because of my experience with XQuartz, which did the same on top of macOS |
| 2025-10-24 15:31:08 | <geekosaur> | It worked poorly |
| 2025-10-24 15:31:37 | <liskin> | Did it? |
All times are in UTC.