2025/10/02

2025-10-02 00:46:17 +0200rascasse(rascasse@user/diep) diep
2025-10-02 01:46:26 +0200hightower3(~hightower@213.186.15.36) hightower2
2025-10-02 01:46:36 +0200srk_(~sorki@user/srk) srk
2025-10-02 01:47:57 +0200srk(~sorki@user/srk) (Remote host closed the connection)
2025-10-02 01:48:58 +0200hightower2(~hightower@213.186.15.36) (Read error: Connection reset by peer)
2025-10-02 01:49:27 +0200srk_srk
2025-10-02 01:51:28 +0200tccq(~user@user/tccq) (Remote host closed the connection)
2025-10-02 03:24:18 +0200rascasse(rascasse@user/diep) (Remote host closed the connection)
2025-10-02 04:45:20 +0200td_(~td@i5387093A.versanet.de) (Ping timeout: 240 seconds)
2025-10-02 04:47:19 +0200td_(~td@i53870901.versanet.de) td_
2025-10-02 08:50:18 +0200ft(~ft@p4fc2a225.dip0.t-ipconnect.de) (Quit: leaving)
2025-10-02 09:13:27 +0200tema(~tema@93.175.2.220)
2025-10-02 09:13:45 +0200tema(~tema@93.175.2.220) (Client Quit)
2025-10-02 09:15:57 +0200Solid(~slot@xmonad/slotThe) slot
2025-10-02 11:24:59 +0200Maeda(~Maeda@91-161-10-149.subs.proxad.net) Maeda
2025-10-02 11:29:34 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63
2025-10-02 11:29:38 +0200 <Maeda> Hi there! Do spawnOnce (from XMonad.Util.SpawnOnce) not honoring a ManagedHook where a rule for a window className to be "insertPosition Below Newer"? For example, closing that window opened at logon and re-opening it makes the 'Below Newer' rule effective as expected (and any further opening of that windows is OK).
2025-10-02 11:40:37 +0200Digit(~user@user/digit) (Remote host closed the connection)
2025-10-02 11:45:10 +0200Digit(~user@user/digit) Digit
2025-10-02 12:43:27 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed)
2025-10-02 13:52:21 +0200mc47(~yecinem@host-212-114-138-22.customer.m-online.net)
2025-10-02 13:52:40 +0200mc47(~yecinem@host-212-114-138-22.customer.m-online.net) (Changing host)
2025-10-02 13:52:40 +0200mc47(~yecinem@xmonad/TheMC47) mc47
2025-10-02 15:22:21 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63
2025-10-02 15:29:03 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed)
2025-10-02 15:31:04 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63
2025-10-02 15:33:27 +0200 <Enrico63> Hi there. I'd like some help debugging an issue with a project of mine. The reason I'd like to ask here is that I can reproduce the bug when logging out of xmonad and back in again. I don't think the bug is in xmonad but in the xmobar status bar, however for obvious reasons I think I can get some help here. I suppose it's a bit OT, but can I ask?
2025-10-02 15:34:02 +0200 <Enrico63> (obviously the bug could be in my project as well, obviously)
2025-10-02 15:35:17 +0200 <Enrico63> The issue has to do with a zombie process left running when logging out of xmonad, I think because it shuts xmobar down which in turns is supposed to shut my plugin down
2025-10-02 15:52:33 +0200PotatoGim(sid99505@id-99505.lymington.irccloud.com) (Ping timeout: 252 seconds)
2025-10-02 15:56:39 +0200PotatoGim(sid99505@id-99505.lymington.irccloud.com) PotatoGim
2025-10-02 16:02:37 +0200Solid`(~slot@uhh-wlan-fo-134-100-17-67.rrz.uni-hamburg.de)
2025-10-02 16:04:13 +0200Solid(~slot@xmonad/slotThe) (Ping timeout: 264 seconds)
2025-10-02 16:22:39 +0200Solid`(~slot@uhh-wlan-fo-134-100-17-67.rrz.uni-hamburg.de) (Quit: ERC 5.6.1-git (IRC client for GNU Emacs 31.0.50))
2025-10-02 16:23:56 +0200 <geekosaur> Maeda, it should be honored but insertPosition plays games with the StackSet and can conflict with a lot of things if done in the wrong order. Try moving that rule relative to manageSpawn
2025-10-02 16:32:41 +0200 <Enrico63> Ok, let me rephrase the question.
2025-10-02 16:32:41 +0200 <Enrico63> Here's the `main` in my `xmonad.hs`:
2025-10-02 16:32:42 +0200 <Enrico63> ```
2025-10-02 16:32:42 +0200 <Enrico63> main :: IO ()
2025-10-02 16:32:43 +0200 <Enrico63> main = xmonad
2025-10-02 16:32:43 +0200 <Enrico63>      . ewmhFullscreen
2025-10-02 16:32:44 +0200 <Enrico63>      . ewmh
2025-10-02 16:32:44 +0200 <Enrico63>      . withEasySB (statusBarProp "xmobar ~/.config/xmobar/xmobar.hs" (clickablePP myXmobarPP)) toggleStrutsKey
2025-10-02 16:32:45 +0200 <Enrico63>      $ myConfig
2025-10-02 16:32:45 +0200 <Enrico63>      where
2025-10-02 16:32:46 +0200 <Enrico63>        toggleStrutsKey XConfig { modMask = m } = (m, xK_b)
2025-10-02 16:32:46 +0200 <Enrico63> ```
2025-10-02 16:32:47 +0200 <Enrico63> What do I know, from this, about what happens to the executable xmobar when I log out of xmonad? How is it shut down? Just like if I had done `kill $(pidof xmobar)`? Or `kill -KILL $(pidof xmobar)`? Or what?
2025-10-02 16:43:00 +0200 <liskin> Enrico63: depends on what "log out of xmonad" means exactly but most likely nothing happens whatsoever
2025-10-02 16:43:02 +0200 <geekosaur> https://hackage.haskell.org/package/xmonad-contrib-0.18.1/docs/XMonad-Hooks-StatusBar.html#v:killS…
2025-10-02 16:43:28 +0200 <liskin> There's no hook when xmonad exits so this function won't be called unless you do it yourself
2025-10-02 16:43:51 +0200 <liskin> (iirc)
2025-10-02 16:44:11 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed)
2025-10-02 16:44:11 +0200 <geekosaur> right, that;'s the other side of it: processes are killed not when xmonad exits but when a new xmonad is spawned (usually what you get woth mod-q)
2025-10-02 16:44:16 +0200 <geekosaur> welp
2025-10-02 16:44:36 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63
2025-10-02 16:44:37 +0200 <liskin> But the X server going away will be noticed by xmobar and it will exit on its own
2025-10-02 16:45:20 +0200 <Enrico63> Sorry, I dropped a sec. Anyway, log out= io exitSuccess
2025-10-02 16:45:24 +0200 <liskin> What happens to processes spawned by it? Similar. If there's a pipe they'll notice and should exit themselves. If there's not a pipe then probably nothing
2025-10-02 16:46:13 +0200 <liskin> Enrico63: that might or might not mean the X server terminates (I run xmonad in a loop so even if it crashes the X stays alive, for example )
2025-10-02 16:46:58 +0200 <Enrico63> With that command, I'm back to the VT, so X is gone
2025-10-02 16:47:50 +0200 <geekosaur> then any processes that weren't terminated will see EOF on their X server sockets and will exit
2025-10-02 16:48:09 +0200 <geekosaur> (XNextEvent() will fail)
2025-10-02 16:48:34 +0200 <Enrico63> geekosaur, I could use that killAllStatusBars to see if I can reproduce the behavior I see without exiting XMobar and X.
2025-10-02 16:50:04 +0200 <Enrico63> Ok, let me give more context. I have xmobar run as I explained above. Then I have a plugin in xmobar that registers a notification server (that I've written). When I exit xmonad as explained, and then log back in, I can register the notificatin server again because the name is still busy, revealing something was left running.
2025-10-02 16:51:52 +0200 <Enrico63> If take xmobar out of the equation and run the notificationi server in a terminal, I can reproduce this zombie behavior by running `kill -KILL $(pidof the-notif-server-running-in-the-other-terminal)`. I'll basically see that the notification server keeps printing notifications in the terminal, even if I killed it. If I try to register a new one, it
2025-10-02 16:51:52 +0200 <Enrico63> fails because the name is busy, just like in the case described above. Luckily, in this case, closing the terminal cleans things up.
2025-10-02 16:52:27 +0200 <Enrico63> I CAN'T register, I meant.
2025-10-02 16:53:01 +0200 <Enrico63> (sorry for caps)
2025-10-02 16:58:50 +0200 <Enrico63> Killing xmobar via killAllStatusBars still leaves things in a good state, in the sense that the notification server is unregistered (if I'm using the right terminology)
2025-10-02 17:18:39 +0200mc47(~yecinem@xmonad/TheMC47) (Ping timeout: 250 seconds)
2025-10-02 17:19:34 +0200 <geekosaur> that makes me think however your xmobar plugin is managing the notification server is wrong, since xmobar should be exiting and hopefully running some plugin deinit first (it may not exit until xmonad starts up again, because we can't kill things at exit so we save them and kill at next startup, but this is guaranteed to happen before starting new bars). if it's not, the notification server may keep running
2025-10-02 17:26:09 +0200 <Enrico63> Mmm. But regarding the fact that I can reproduce the "zombi" scenario by killing the notification server (when I run it as standalone from a terminal) via `kill -KILL`... that's not a proof on its own that there's a bug, right? I mean -KILL means that no chance is given to the process to clean up anything, am I correct?
2025-10-02 17:26:35 +0200 <geekosaur> correct
2025-10-02 17:27:09 +0200 <geekosaur> but it's rare for anything to use -KILL directly; the convention is -TERM, wait 5-10 seconds, -KILL if the process hasn't exited on its own
2025-10-02 17:27:45 +0200 <geekosaur> to keep stuck processes from blocking an entire "stack" from shutting down
2025-10-02 17:27:58 +0200 <Enrico63> I see
2025-10-02 17:32:58 +0200 <liskin> Is this notification server a separate process?
2025-10-02 17:34:38 +0200 <liskin> If yes and it expects to be terminated by a signal, then that's fraught with disappointment. Nothing, apart from xmonad's dynamicSBs, sends signals. Even dynamicSBs doesn't send them on exit, only on rescreen.
2025-10-02 17:35:15 +0200 <liskin> You'll need to find another way. And you'll need to learn a bit about signals and pipes and processes and such.
2025-10-02 17:35:37 +0200 <liskin> Or you can do what I do and just let systemd manage everything. :-)
2025-10-02 17:35:58 +0200 <Enrico63> Ok, that assumes my understanding of how xmobar spawns the `IO` actions provided by the plugins. Let me check
2025-10-02 17:36:24 +0200 <liskin> I just run xmobar "plug-ins" as completely separate systemd services that write into X props and xmobar reads from them. Works like a charm.
2025-10-02 17:37:11 +0200 <liskin> (but getting that to work with multiple X sessions means straying so far from the beaten path it's not even fun)
2025-10-02 17:37:46 +0200 <Enrico63> Well, at the moment I'm more curious about understanding what's going on with my setting. I mean, the bug can easily be in my notification server.
2025-10-02 17:38:11 +0200 <geekosaur> or in xmobar or your plugin, as I said
2025-10-02 17:39:03 +0200 <geekosaur> lots of moving parts here, and it's sufficiently distant from xmonad that that's unlikely to be involved if xmobar is getting killed/restarted correctly; that fingers the plugin or thenotification server
2025-10-02 17:42:13 +0200 <Enrico63> The IO action I use the start the server is here https://codeberg.org/Aster89/xnobar/src/commit/7a445e8302db800b214dcc7f11562cc06f854dd3/lib/Server…
2025-10-02 17:42:13 +0200 <Enrico63> The `reply == NamePrimaryOwner` means that the registration happened successfully, in which case I pass `Right (notifications, revoke)` down the following computation, but `revoke` is an IO action that undos what I've done in the linked code. And at
2025-10-02 17:42:14 +0200 <Enrico63> https://codeberg.org/Aster89/xnobar/src/commit/7a445e8302db800b214dcc7f11562cc06f854dd3/lib/XNobar… I try to be careful to run that `finally`.
2025-10-02 17:42:47 +0200 <Enrico63> With that, I think I'm ensuring that things are clean up correctly, at least if I don't kill with -KILL.
2025-10-02 17:43:25 +0200 <Enrico63> Does it sound sensible, or am I saying crap? :/
2025-10-02 17:45:31 +0200 <liskin> That assumes xmobar terminates its threads cleanly and waits for them
2025-10-02 17:45:36 +0200 <liskin> I wouldn't bet it does
2025-10-02 17:45:45 +0200 <geekosaur> there's one key piece missing: how, if at all, does xmobar tell your plugin to deinitialize?
2025-10-02 17:45:52 +0200 <Enrico63> The fact that, when I run the notif server in a terminal, killing it with -KILL leaves it running like a zombi and when i kill it without KILL it is shut down and I can restart it, leads me to think that my notif server is behaving well
2025-10-02 17:46:16 +0200 <liskin> Wait what
2025-10-02 17:46:29 +0200 <liskin> If you KILL then it's running? Wtf
2025-10-02 17:46:30 +0200 <geekosaur> it's entirely possible that it assumes plugins don't do anything persisten
2025-10-02 17:46:33 +0200 <geekosaur> t
2025-10-02 17:46:45 +0200 <Enrico63> liskin gimme a moment to re-read my msg
2025-10-02 17:46:51 +0200 <geekosaur> liskin, -KILL prevents cleanup, so the server isn't reaped
2025-10-02 17:47:21 +0200 <liskin> geekosaur: they didn't say killing xmobar, they said killing notif server
2025-10-02 17:47:37 +0200 <Enrico63> Oh, yeah, liskin, if I kill -KILL the notification server, I see it keeps running. even if the PID is gone
2025-10-02 17:47:40 +0200 <geekosaur> also, wrt the server itself, -KILL means not being able to tell dbus to deregster the name
2025-10-02 17:47:57 +0200 <Enrico63> Yes, @geee
2025-10-02 17:48:06 +0200 <geekosaur> so registering it again will fail without a flag to reuse the name
2025-10-02 17:48:10 +0200 <Enrico63> yes, geekosaur, that's why I think it's normal that it keeps running in that case
2025-10-02 17:48:11 +0200 <liskin> But yeah if C-Cing xmobar evals the finally, that's a hint maybe it does actually wait for the threads
2025-10-02 17:49:21 +0200 <geekosaur> also, if the pid is gone, the server is gone. but its registration with dbus may still be there
2025-10-02 17:50:01 +0200 <Enrico63> liskin, eh... but I actually added that finally just an attempt to fix this issue. I had forgotten to do any deristration before, and it would stil bheave the same (i.e. react well when I, say, kill xmobar, or restart xmonad in place, and it would leave the name busy when logging out of xmonad)
2025-10-02 17:50:05 +0200 <geekosaur> sometimes this is just something you must deal with. https://github.com/geekosaur/xmonad.hs/blob/hilfy-2023/xmonad.hs#L448-L450
2025-10-02 17:51:11 +0200 <Enrico63> > also, if the pid is gone, the server is gone. but its registration with dbus may still be there
2025-10-02 17:51:11 +0200 <Enrico63> yea, geekosaur, I think that is what happens when I exit xmonad. And I tend to  think that it's because xmobar kills me too harshly, like with KILL.
2025-10-02 17:51:12 +0200 <lambdabot> <hint>:1:5: error: parse error on input ‘,’
2025-10-02 17:51:43 +0200 <liskin> So did we at least establish whether the process is still running?
2025-10-02 17:51:56 +0200 <liskin> If not and dbus refuses then what geekosaur says
2025-10-02 17:52:00 +0200 <geekosaur> quote with something other than "> ", lambdabot takes that as code to run
2025-10-02 17:52:17 +0200 <geekosaur> they said the pid is gone, so it's not running
2025-10-02 17:52:19 +0200 <Enrico63> Sorry, I didn't know that :(
2025-10-02 17:52:21 +0200 <liskin> If yes then it's an issue of process lifetimes and signalling
2025-10-02 17:52:38 +0200 <Enrico63> If you give me a moment I can record a GIF
2025-10-02 17:52:46 +0200 <Enrico63> well, more than a moment
2025-10-02 17:52:52 +0200 <liskin> (afk now, sry)
2025-10-02 18:01:13 +0200 <Enrico63> Here's the GIF showing my repro https://codeberg.org/Aster89/xnobar/attachments/03972518-6532-4594-b632-62bf39030453
2025-10-02 18:20:24 +0200 <geekosaur> okay, that proves killing xmobar doesn't do anything. I think liskin was asking about your notification server itself
2025-10-02 18:20:28 +0200 <Enrico63> The IO action I defined in my plugin is run here: https://codeberg.org/xmobar/xmobar/src/commit/4e8ec5a4c86873018f3ba33669fb9affff280d6e/src/Xmobar/… via `async`
2025-10-02 18:21:29 +0200 <Enrico63> geekosaur, I might have misunderstood what I was asked. What about the notification server?
2025-10-02 18:24:08 +0200 <geekosaur> you said its pid had gonee away but it was still running. by "its pid had gone away" did you mean xmobar, or the notification server itself?
2025-10-02 18:30:00 +0200 <Enrico63> When I said that I was talking of the scenario I've shown in the GIF, that is when take xmobar out of the equation and run the notification server manually in a terminal.
2025-10-02 18:30:30 +0200 <Enrico63> In that case, the PID is the PID of the `cabal run` that I enter in the terminal to run the notification server.
2025-10-02 18:34:04 +0200 <Enrico63> So I'm just making the hypothesis that when I exit xmonad, xmobar (at some point) is shutting down my notification sever in a way similar to what I can do via kill -KILL when I run my notification sever standalone, i.e. in a way that doesn't give it a chance to unregister from dbus.
2025-10-02 18:35:10 +0200 <Enrico63> But I don't know how to see if that's the case. I think the clean up of xmobar's plugins happens via this function: https://codeberg.org/xmobar/xmobar/src/commit/4e8ec5a4c86873018f3ba33669fb9affff280d6e/src/Xmobar/…
2025-10-02 18:36:33 +0200 <Enrico63> But `cancel` seem to do the right thing, according to the doc: https://hackage.haskell.org/package/async-2.2.5/docs/Control-Concurrent-Async-Internal.html#v:cancel
2025-10-02 18:39:04 +0200 <liskin> What do you mean by you don't know how to see? Just login as root from vt1 and do ps axf after you've shut down X?
2025-10-02 18:39:41 +0200 <liskin> (or even perhaps login as your user if you don't use user systemd to manage the X session)
2025-10-02 18:39:42 +0200 <Enrico63> To see what? If xmobar is running or not?
2025-10-02 18:40:04 +0200 <liskin> Probably a good idea to not limit yourself to xmobar.
2025-10-02 18:40:16 +0200 <liskin> To see everything. What's still running and what's not.
2025-10-02 18:40:49 +0200 <Enrico63> Ok, but I have to know what to look for, no?
2025-10-02 18:41:01 +0200 <Enrico63> Just saying I don't know what else to look for.
2025-10-02 18:41:23 +0200 <Enrico63> Except I'd wander about my notification server, but is that a _process_?
2025-10-02 18:41:47 +0200 <Enrico63> As in, if the IO action is run via async... then it won't have a PID associated, or would it?
2025-10-02 18:42:53 +0200 <liskin> If it's not a separate process then yeah xmobar
2025-10-02 18:44:09 +0200 <Enrico63> On this line here https://codeberg.org/xmobar/xmobar/src/commit/4e8ec5a4c86873018f3ba33669fb9affff280d6e/src/Xmobar/… `start` is the thing I define in my plugin. It is run via `async`. So the conclusion is that it's not a separate process, right? Is just a separate thread
2025-10-02 18:48:16 +0200 <liskin> Yeah
2025-10-02 18:48:47 +0200 <geekosaur> your plugin, yes. but if you spawn something, that will be a separate process. (it's also playing with fire, as mixing threads and processes is unsafe in any language. fork+immediate exec is usually safe, but still has potential for crashes)
2025-10-02 18:52:20 +0200 <Enrico63> "but if you spawn something" -> does registering with dbus count?
2025-10-02 18:52:49 +0200 <geekosaur> no
2025-10-02 18:53:02 +0200 <geekosaur> you are running a notification server which is a separate process
2025-10-02 18:54:24 +0200 <Enrico63> Yeah, but I'm not spawning anything, as far as I know. I'm just using DBus API
2025-10-02 18:55:21 +0200 <geekosaur> wait, this is all running inside of xmobar, then?
2025-10-02 18:57:12 +0200 <geekosaur> okay, I see, it's just a library. so if xmobar exits the thread shouldn't exist any more (when the main thread of a process exits, all other threads are hard-killed)
2025-10-02 18:57:49 +0200 <Enrico63> Oh, crap, where am I unclear? :'(
2025-10-02 18:57:49 +0200 <Enrico63> 1. My  understanding is that the `IO` action I define in my plugin is run by xmobar via `async`.
2025-10-02 18:57:50 +0200 <Enrico63> 2. The `IO` action I define in my plugin takes care of registering with DBus
2025-10-02 18:57:50 +0200 <Enrico63> 3. Incidentally I do also spawn so process, but for doing toher stuff like creating a pipe, writing into it, but that's  I believe what you refer to as fork+exec
2025-10-02 18:58:01 +0200 <Enrico63> *spawn some processe
2025-10-02 18:58:35 +0200 <Enrico63> Does "hard-killed" mean "no chance of clean up"?
2025-10-02 18:59:44 +0200 <geekosaur> yes
2025-10-02 19:00:25 +0200 <Enrico63> Then that doesn't fit with my objservations either. Because if instead of quitting xmonad I simply kill (even with -KILL) xmobar, then the dbus registration is not left hanging there
2025-10-02 19:00:26 +0200 <geekosaur> this is forced by the OS; if the process needs to do thread cleanup, it needs to signal threads to clean up and wait for them to exit before it exits
2025-10-02 19:16:57 +0200 <geekosaur> I'm going to have to leave soon so I can't poke at this any more right now, sorry
2025-10-02 19:20:41 +0200 <Enrico63> No problem. I'm collecting anyway the info here https://codeberg.org/Aster89/xnobar/issues/15 so asking another day I can refer to that, if that's ok
2025-10-02 19:21:04 +0200 <Enrico63> But thanks :)
2025-10-02 19:30:33 +0200 <liskin> Maybe when xmobar loses its X connection it doesn't exit as cleanly as when you sigterm or sigint it?
2025-10-02 19:30:57 +0200 <liskin> Either way, if xmobar isn't running and you still can't register on dbus, that's between you and dbus.
2025-10-02 19:31:05 +0200 <liskin> The two of you need to agree.
2025-10-02 19:31:30 +0200 <liskin> <geekosaur> sometimes this is just something you must deal with. https://github.com/geekosaur/xmonad.hs/blob/hilfy-2023/xmonad.hs#L448-L450
2025-10-02 19:31:35 +0200 <liskin> This way maybe
2025-10-02 19:34:18 +0200 <Enrico63> "if xmobar isn't running and you still can't register on dbus". No, if xmobar isn't running, which I  means I'm running my notif server as a **process**, then if I want to get in the situation where I can't register is that I register and then `kill -KILL` my notif server. But in that case, geekosaur has confirmed that's normal, as -KILL means no
2025-10-02 19:34:18 +0200 <Enrico63> chance for clean up is given.
2025-10-02 19:38:38 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed)
2025-10-02 19:39:33 +0200ft(~ft@p4fc2a225.dip0.t-ipconnect.de) ft
2025-10-02 19:43:59 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63
2025-10-02 19:50:35 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed)
2025-10-02 19:55:29 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63
2025-10-02 19:56:56 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Client Quit)
2025-10-02 20:41:16 +0200rascasse(~rascasse@user/diep) diep
2025-10-02 21:04:23 +0200 <rascasse> Hi, because Im very bad with Haskell Im stuck trying to not apply window/screen spacing on the "Full" layout. I just want them for my other layouts. When I switch to Full, I want any spacing to be turned off for fullscreen experience. This is my layouts config https://b.deip.fr/p/mole-worm-shark Note for spacing Im using https://xmonad.github.io/xmonad-docs/xmonad-contrib-0.18.1.9/XMonad-Layout-Spacing.html
2025-10-02 21:05:03 +0200 <rascasse> Can someone help me to configure that? (if it is possible)
2025-10-02 21:07:53 +0200 <rascasse> I think I need to use setWindowSpacingEnabled False somewhere, but as I said I fail because I dont know haskell syntax
2025-10-02 21:28:48 +0200Maeda(~Maeda@91-161-10-149.subs.proxad.net) (Quit: BRB)
2025-10-02 21:47:22 +0200Maeda(~Maeda@91-161-10-149.subs.proxad.net) Maeda
2025-10-02 21:50:04 +0200 <Maeda> geekosaur: Thanks for highlighting this to me. Two changes I've done and now it works. First, add spawnManage before manageHook def (i.e., `manageSpawn <> manageHook def`) and move my MymanageHook rule that defines the insertPostion at the top of the rules. All OK! Once again, your help was greatly appreciated!
2025-10-02 22:35:28 +0200 <geekosaur> you think wrong because that's not how layouts work. generally you need to apply the spacing modifier only to the layouts you want to use it with
2025-10-02 22:37:36 +0200 <geekosaur> rascasse, https://bin.deip.fr/upload/mole-worm-shark
2025-10-02 22:40:42 +0200 <geekosaur> incidentally, that pastebin isa bit buggy: it backslashes $ when you edit, and when I went to remove them it backslashed them again first…
2025-10-02 22:40:45 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63
2025-10-02 22:41:24 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Client Quit)
2025-10-02 22:42:34 +0200 <rascasse> thx! just to check then `$ spacingWithEdge 9 (tiled ||| mirror) ||| full` is correct right?
2025-10-02 22:42:44 +0200 <rascasse> it compiles
2025-10-02 22:42:52 +0200 <rascasse> it works!
2025-10-02 22:43:03 +0200 <rascasse> man thanks geekosaur
2025-10-02 22:43:09 +0200 <rascasse> many thanks*
2025-10-02 22:43:21 +0200 <rascasse> but
2025-10-02 22:44:09 +0200 <rascasse> for some reason when switching to Full xmobar does not draw the square icon as expected, but nothing is printed
2025-10-02 22:44:36 +0200 <rascasse> no issue with other layers
2025-10-02 22:45:47 +0200 <rascasse> that's my xmobar setup if it can helps https://b.deip.fr/p/ape-raven-pig
2025-10-02 22:45:57 +0200 <geekosaur> does changing Full to Simplest help?
2025-10-02 22:46:35 +0200 <geekosaur> (Full is a completely blank layout, which confuses some layout modifiers)
2025-10-02 22:48:01 +0200 <geekosaur> that said, Renamed shouldn't be affected by the difference
2025-10-02 22:48:10 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63
2025-10-02 22:48:31 +0200 <rascasse> nope same issue
2025-10-02 22:50:22 +0200 <rascasse> XMonad.Layout.Simplest right?
2025-10-02 22:50:28 +0200 <geekosaur> right
2025-10-02 22:50:58 +0200 <geekosaur> oh, I think I know. move the outer `renamed` so it applies only to `spacingWithEdge`
2025-10-02 22:51:15 +0200 <geekosaur> otherwise, since the leftmost word of the full layout is the square, it's removed
2025-10-02 22:52:59 +0200 <rascasse> renamed [CutWordsLeft 1] this one ?
2025-10-02 22:53:15 +0200 <geekosaur> https://bin.deip.fr/upload/mole-worm-shark
2025-10-02 22:53:46 +0200 <rascasse> my gosh Haskell ><
2025-10-02 22:54:03 +0200 <rascasse> my small brain hurt
2025-10-02 22:54:05 +0200 <rascasse> xD
2025-10-02 22:54:17 +0200 <geekosaur> actually there's some unneeded parens there
2025-10-02 22:54:51 +0200 <geekosaur> okay reload, since it's giving me the same urls
2025-10-02 22:55:28 +0200 <rascasse> yep will try 2sec
2025-10-02 22:55:29 +0200 <geekosaur> sorry, it backslashed my $s again, try it now
2025-10-02 22:57:49 +0200 <rascasse> yea I spotted it
2025-10-02 22:57:57 +0200 <rascasse> but does not compile
2025-10-02 22:58:35 +0200 <rascasse> https://b.deip.fr/p/otter-dove-koala
2025-10-02 22:58:55 +0200 <geekosaur> which version did you get? I had a version saved where the pastebin threw a bunch of backslashes into it that would break it
2025-10-02 22:59:14 +0200 <rascasse> no backslashes
2025-10-02 22:59:35 +0200 <rascasse> with `spaced = renamed [CutWordsLeft 1] $ spacingWithEdge 9`
2025-10-02 22:59:53 +0200 <rascasse> and `$ spaced (tiled ||| mirror) ||| full`
2025-10-02 23:00:29 +0200 <geekosaur> right, LayoutClass vs. type inference 😕
2025-10-02 23:02:19 +0200 <rascasse>
2025-10-02 23:03:03 +0200 <geekosaur> this will be ugly, I'm afraid
2025-10-02 23:03:38 +0200 <rascasse> 🙈
2025-10-02 23:03:49 +0200 <rascasse> lets see
2025-10-02 23:06:13 +0200 <geekosaur> https://bin.deip.fr/upload/mole-worm-shark
2025-10-02 23:09:58 +0200 <rascasse> ah need to import ModifiedLayout
2025-10-02 23:12:31 +0200 <geekosaur> also it's wrong anyway, I'm poking
2025-10-02 23:12:39 +0200 <rascasse> ah ok
2025-10-02 23:13:04 +0200 <rascasse> couldn't find from where to import it anyway
2025-10-02 23:13:24 +0200 <rascasse> https://b.deip.fr/p/goose-dove
2025-10-02 23:13:32 +0200 <rascasse> compile error
2025-10-02 23:16:28 +0200Enrico63(~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed)
2025-10-02 23:19:03 +0200 <geekosaur> oyes, I said it was broken
2025-10-02 23:19:14 +0200 <geekosaur> https://bin.deip.fr/upload/mole-worm-shark less ugly than I thought and doesn't need the import
2025-10-02 23:22:51 +0200 <rascasse> testing!
2025-10-02 23:24:22 +0200 <rascasse> yup I confirm fixed
2025-10-02 23:24:31 +0200 <rascasse> thanks again!
2025-10-02 23:27:24 +0200 <rascasse> much better for this layout
2025-10-02 23:28:47 +0200 <rascasse> btw, in Full is it possible to have the window drawn ontop of xmobar?
2025-10-02 23:29:08 +0200 <rascasse> draw*
2025-10-02 23:30:05 +0200 <rascasse> perhaps there is another way to toggle "fullscreen" for a given window?
2025-10-02 23:30:12 +0200 <rascasse> I dont remember
2025-10-02 23:31:14 +0200 <geekosaur> you need to make avoidStruts not apply to it
2025-10-02 23:35:39 +0200 <rascasse> I see
2025-10-02 23:37:09 +0200 <rascasse> got it `$ avoidStruts (spaced (tiled ||| mirror)) ||| full`
2025-10-02 23:39:52 +0200 <geekosaur> I'd've just added it to spaced, but whatever
2025-10-02 23:40:43 +0200 <geekosaur> there's also a trickier version if you want to try it at some point: https://github.com/geekosaur/xmonad.hs/blob/hilfy-2023/xmonad.hs#L183-L184
2025-10-02 23:41:21 +0200 <geekosaur> that is, on `Full` you use that `avoidStrutsOn []`, which means you can toggle the xmobar visible if you need to but by default it's hidden
2025-10-02 23:42:28 +0200 <rascasse> `spaced l= renamed [CutWordsLeft 1] $ avoidStruts $ spacingWithEdge 9 $ l` yes much cleaner
2025-10-02 23:44:06 +0200 <rascasse> interesting
2025-10-02 23:44:34 +0200 <geekosaur> you can also put a space before the = there, I was just maintaining spacing without editing the other lines
2025-10-02 23:46:42 +0200 <rascasse> yes I know, but same I prefer preserving the indent
2025-10-02 23:47:08 +0200 <geekosaur> could just reindent the other lines too, I was just being lazy 🙂
2025-10-02 23:49:11 +0200 <rascasse> yes ser
2025-10-02 23:50:36 +0200 <rascasse> how it looks now https://b.deip.fr/p/bear-swan-bird
2025-10-02 23:51:43 +0200 <rascasse> just realizing now I dont need to rename Full
2025-10-02 23:51:45 +0200 <rascasse> anymore
2025-10-02 23:51:59 +0200 <rascasse> since xmobar is hidden anyway
2025-10-02 23:57:25 +0200 <rascasse> keeps surprised how flexible Xmonad is, and so, powerful
2025-10-02 23:59:44 +0200 <rascasse> it justs hurt a bit to write the Haskell config, but thankfully with some help form geekosaur everything is possible 😁