Home liberachat/#xmonad: Logs Calendar

Logs on 2021-09-13 (liberachat/#xmonad)

01:45:11 pankratius joins (~pankratiu@2a01:e34:ec49:2080:aee1:9c62:27b9:9853)
01:46:05 × pankratius quits (~pankratiu@2a01:e34:ec49:2080:aee1:9c62:27b9:9853) (Client Quit)
02:03:46 × banc quits (banc@gateway/vpn/airvpn/banc) (Ping timeout: 252 seconds)
02:11:21 × td_ quits (~td@muedsl-82-207-238-026.citykom.de) (Ping timeout: 265 seconds)
02:13:12 td_ joins (~td@94.134.91.246)
02:24:15 banc joins (banc@gateway/vpn/airvpn/banc)
02:27:25 × benin03693230 quits (~benin@183.82.24.227) (Ping timeout: 252 seconds)
02:48:35 × abhixec quits (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
02:57:38 × eb0t quits (~eb0t@90.209.54.144) (Quit: WeeChat 2.3)
03:08:41 defjam joins (~eb0t@90.209.54.144)
03:09:07 defjam is now known as eblip
04:06:04 × iffsid quits (~iffsid@2001:470:69fc:105::a3e) (*.net *.split)
04:06:04 × TheWizardTower[m quits (~thewizard@2001:470:69fc:105::a5b) (*.net *.split)
04:06:04 × mc47[m] quits (~mc47matri@2001:470:69fc:105::733) (*.net *.split)
04:06:04 × Industrial[m] quits (~industria@2001:470:69fc:105::eb9) (*.net *.split)
04:06:04 × ghormoon quits (~ghormoon@ghorland.net) (*.net *.split)
04:06:04 × deebo quits (~globe@stonebay32.com) (*.net *.split)
04:07:32 ghormoon joins (~ghormoon@ghorland.net)
04:11:05 Industrial[m] joins (~industria@2001:470:69fc:105::eb9)
04:11:14 deebo joins (~globe@stonebay32.com)
04:14:23 mc47[m] joins (~mc47matri@2001:470:69fc:105::733)
04:14:36 TheWizardTower[m joins (~thewizard@2001:470:69fc:105::a5b)
04:14:38 iffsid joins (~iffsid@2001:470:69fc:105::a3e)
04:19:16 × M0x604[m] quits (~M0x604mat@2001:470:69fc:105::e21c) (*.net *.split)
04:19:16 × syntactic_sugar[ quits (~syntactic@2001:470:69fc:105::b4af) (*.net *.split)
04:19:17 × M-elo-[m] quits (~gilganixm@2001:470:69fc:105::3d09) (*.net *.split)
04:19:17 × fakecrafter[m] quits (~fakecraft@2001:470:69fc:105::a38) (*.net *.split)
04:19:17 × VarikValefor[m] quits (~varikvale@2001:470:69fc:105::a5d) (*.net *.split)
04:19:17 × rednaZ[m] quits (~r3dnazmat@2001:470:69fc:105::ba70) (*.net *.split)
04:19:17 × SimonWeiss[m] quits (~weiss-dma@2001:470:69fc:105::bebd) (*.net *.split)
04:19:17 × Rockj quits (~rockj@chromie.geekrevolution.net) (*.net *.split)
04:19:17 × fizzie quits (irc@selene.zem.fi) (*.net *.split)
04:19:49 Rockj joins (~rockj@chromie.geekrevolution.net)
04:20:16 fizzie joins (irc@selene.zem.fi)
04:20:25 M0x604[m] joins (~M0x604mat@2001:470:69fc:105::e21c)
04:23:42 syntactic_sugar[ joins (~syntactic@2001:470:69fc:105::b4af)
04:24:44 SimonWeiss[m] joins (~weiss-dma@2001:470:69fc:105::bebd)
04:25:17 rednaZ[m] joins (~r3dnazmat@2001:470:69fc:105::ba70)
04:25:25 VarikValefor[m] joins (~varikvale@2001:470:69fc:105::a5d)
04:27:30 benin03693230 joins (~benin@183.82.24.227)
04:30:11 fakecrafter[m] joins (~fakecraft@2001:470:69fc:105::a38)
04:30:15 M-elo-[m] joins (~gilganixm@2001:470:69fc:105::3d09)
04:41:46 × benin03693230 quits (~benin@183.82.24.227) (Ping timeout: 268 seconds)
05:06:24 × geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
05:09:25 geekosaur joins (~geekosaur@xmonad/geekosaur)
06:10:54 × cjb quits (~cjbayliss@user/cjb) ()
06:40:50 AndrewIRC is now known as AndrewYu
07:23:05 cfricke joins (~cfricke@user/cfricke)
07:43:15 benin03693230 joins (~benin@183.82.24.227)
08:17:44 × geekosaur quits (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b)))
08:17:44 allbery_b joins (~geekosaur@xmonad/geekosaur)
08:17:47 allbery_b is now known as geekosaur
09:00:06 × gate32[m] quits (~gate32mat@2001:470:69fc:105::9e3) (Quit: You have been kicked for being idle)
09:30:54 × geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
09:33:40 geekosaur joins (~geekosaur@xmonad/geekosaur)
10:45:18 cafkafk is now known as cafkafk-on-erc
10:45:23 cafkafk-on-erc is now known as cafkafk
12:04:55 dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net)
12:09:43 × td_ quits (~td@94.134.91.246) (Ping timeout: 265 seconds)
12:23:02 <mc47[m]> Solid : did you figure out how to build your setup without relying on a build script?
12:42:35 × thunderrd quits (~thunderrd@183.182.114.10) (Ping timeout: 265 seconds)
12:53:14 <Solid> mc47[m]: yes; https://gitlab.com/slotThe/dotfiles/-/commit/25230b3171cba665ca39fba5d666a1792ee6c21f
12:53:33 <Solid> I have sinced reverted that commit for unknown reasons, but I definitely remember it working :D
12:56:24 thunderrd joins (~thunderrd@183.182.110.127)
12:59:32 <mc47[m]> I'll give it a try, because I couldn't make it work
12:59:35 <mc47[m]> Thank you!
13:01:39 <Solid> if a dev couldn't make it work then we definitely either need more docs or a more robust handling of the stack story :)
13:04:19 <mc47[m]> I know very little about stack, but I'll give my feedback when I figure this out (probably not today, but it depends if I'm motivated to work in a train)
13:09:17 × thunderrd quits (~thunderrd@183.182.110.127) (Ping timeout: 268 seconds)
13:21:19 td_ joins (~td@94.134.91.92)
13:34:14 thunderrd joins (~thunderrd@183.182.114.40)
13:49:23 × dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.2.1)
14:01:45 rekahsoft joins (~rekahsoft@52.129.35.150)
14:02:49 × rekahsoft quits (~rekahsoft@52.129.35.150) (Remote host closed the connection)
14:03:31 rekahsoft joins (~rekahsoft@52.129.35.150)
14:05:43 × rekahsoft quits (~rekahsoft@52.129.35.150) (Remote host closed the connection)
14:08:12 rekahsoft joins (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
14:20:28 × qbt quits (~edun@user/edun) (Quit: WeeChat 3.2)
14:26:28 <electr0n> Solid: how do you like KMonad? Been meaning to take it for a spin.
14:52:58 xmonadcool joins (~xmonadcoo@5-15-55-28.residential.rdsnet.ro)
14:53:02 <xmonadcool> hi
14:54:34 <xmonadcool> i wanna get tray icons in xmobar, found a thread on stackexchange but it has a really unusual way of doing it
14:54:53 <xmonadcool> apparently if you leave a small gap in your xmobar for stalone tray
14:54:56 <xmonadcool> itll work
14:55:20 <xmonadcool> but i think thats unsual since what if i have more apps open and itll override xmobar
14:55:26 <xmonadcool> i wouldnt like that
14:55:39 <xmonadcool> how can i automatically expand xmobar depending on my tray icons?
15:02:50 <electr0n> you will need something like trayer or standalonetray
15:04:07 <Solid> electr0n: I think I'm obliged to say that I love it because I have a commit bit :>
15:04:19 <Solid> but seriously, it's so great not having to edit .xmodmap files anymore
15:04:44 <Solid> I couldn't use Emacs without it :)
15:05:52 <Solid> xmonadcool: a lot of people seem to like this method: https://github.com/jaor/xmobar/issues/239#issuecomment-233206552
15:17:54 <electr0n> I am messing with doing simple decorations on just 1 side of the window, and for the most part its working, I just cannot figure out why it also draws something on the top and displays the window title.
15:23:11 × xmonadcool quits (~xmonadcoo@5-15-55-28.residential.rdsnet.ro) (Quit: Client closed)
15:27:40 seschwar joins (~seschwar@user/seschwar)
15:38:31 <electr0n> any recommendations?
15:49:46 × rekahsoft quits (~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Ping timeout: 260 seconds)
15:54:07 × amir quits (sid22336@user/amir) ()
15:54:23 amir joins (sid22336@user/amir)
16:25:55 × cfricke quits (~cfricke@user/cfricke) (Quit: WeeChat 3.2)
17:11:14 × thunderrd quits (~thunderrd@183.182.114.40) (Ping timeout: 268 seconds)
17:19:02 × geekosaur quits (~geekosaur@xmonad/geekosaur) (Ping timeout: 268 seconds)
17:19:33 geekosaur joins (~geekosaur@xmonad/geekosaur)
17:21:32 × electr0n quits (~electr0n@about/security/founder/electr0n) (Quit: WeeChat 3.2)
17:22:10 electr0n joins (~electr0n@about/security/founder/electr0n)
17:23:36 thunderrd joins (~thunderrd@183.182.110.40)
18:11:40 × electr0n quits (~electr0n@about/security/founder/electr0n) (Ping timeout: 268 seconds)
18:28:24 × geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
18:28:44 geekosaur joins (~geekosaur@xmonad/geekosaur)
18:53:03 × redgloboli quits (~redglobol@user/redgloboli) (Remote host closed the connection)
18:53:22 redgloboli joins (~redglobol@user/redgloboli)
19:21:33 abhixec joins (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net)
19:38:03 <elonsroadster[m]> <xmonadcool> "i wanna get tray icons in xmobar..." <- Have you looked at taffybar?
19:40:44 <elonsroadster[m]> xmonadcool I'm the author so obviously a bit biased, but it was sort of made explicitly because doing things like having a proper tray is so hard in xmobar. Taffybar is also written in haskell, and has really good tray support built in
19:43:16 <elonsroadster[m]> <nurnochgeist> "say i have a workspace that..." <- I think the right approach to solving the problem you describe here is to have a way to replace a window in a layout with an existing window (possibly in another workspace or minimized) Here is a function which does this: https://github.com/IvanMalison/dotfiles/blob/f36ddc4cdd155e4dbb264092dcb6c896713b05e6/dotfiles/config/xmonad/xmonad.hs#L540
19:46:26 <elonsroadster[m]> nurnochgeist: I see that liskin already suggested windowGo/windowBring, but this does not *quite* do what you want. I also realized that while the function I linked you does do exactly what you want, it also has a bunch of custom stuff that is related to my config. What you really want to look at is swapFocusedWith (see
19:46:26 <elonsroadster[m]> https://github.com/IvanMalison/dotfiles/blob/f36ddc4cdd155e4dbb264092dcb6c896713b05e6/dotfiles/config/xmonad/xmonad.hs#L786) and something like my
19:47:08 <elonsroadster[m]> * nurnochgeist: I see that liskin already suggested windowGo/windowBring, but this does not _quite_ do what you want. I also realized that while the function I linked you does do exactly what you want, it also has a bunch of custom stuff that is related to my config. What you really want to look at is swapFocusedWith (see
19:47:08 <elonsroadster[m]> https://github.com/IvanMalison/dotfiles/blob/f36ddc4cdd155e4dbb264092dcb6c896713b05e6/dotfiles/config/xmonad/xmonad.hs#L786) and something like windowAct
19:47:08 <elonsroadster[m]> If it's helpful, I'd be happy to make a PR to add something like swapFocusedWith to the windowBringer module.
19:49:28 <elonsroadster[m]> <liskin> "so, um, is this active refusal..." <- liskin: That's a pretty unnecessarily uncharitable way to start a dialogue...
19:49:52 <elonsroadster[m]> Where do you see ACTIVE refusal to document anything on my part?
19:52:58 × thunderrd quits (~thunderrd@183.182.110.40) (Ping timeout: 252 seconds)
19:54:37 <elonsroadster[m]> Also, I went out of my way to add nix support in https://github.com/xmonad/xmonad/pull/330 for a feature that I don't even use, because of your complaint that we have a flake.nix, but self-recompilation is not supported with that flake.
19:59:22 × abhixec quits (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Ping timeout: 268 seconds)
20:01:34 <elonsroadster[m]> FURTHERMORE, (you can be forgiven for not understanding this since you aren't familiar with nix), but the complaint doesn't even really make THAT much sense. Self-compilation IS supported through the xmonad nixpkgs module, which is what most (especially those who are newer to nix haskell will use anyway).... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/f676643b5f8f1d4badfe72de2225e432cdcd730a)
20:04:28 <elonsroadster[m]> When I originally wrote the flake, I figured that most of these use cases would be things that only power users (people already familiar with both haskell and nix (and specifically nix flakes)) would want to do.
20:04:28 <elonsroadster[m]> I think that this actually WILL be true in the future, but at the moment, because there are so many changes on master that have not yet made it into a release, there is quite a lot of interest in running from git master, even among those less familiar with nix/haskell.
20:06:46 <liskin> elonsroadster[m]: well, it wasn't as much starting a discussion as me venting my frustration.
20:06:48 <elonsroadster[m]> The super random issue that you seem to have found is a case of a less experienced user trying to run from master, but also trying to copy aspects of my xmonad setup (something I generally advise people, especially those who are less experienced not to do).
20:07:32 <elonsroadster[m]> liskin: I think you should reconsider whether its actually fair for you to feel frustrated at me in this situation.
20:08:42 <liskin> elonsroadster[m]: we two seem to have communication problems going back years, so I do think it is fair to be frustrated; you do not need to take that personally if you believe our misunderstandings are largely my fault
20:11:17 <elonsroadster[m]> How would I not take someone calling me out (while also denigrating a tool that I obviously like and use) in a public setting personally?
20:11:39 <elonsroadster[m]> that seems like a totally natural response to me.
20:12:05 <liskin> elonsroadster[m]: One example of this communication problem is that you seem to think I complained about the lack of support for recompilation, while I'm quite convinced I merely complained that it is not documented how to recompile, or how to use the nix flake in general.
20:12:31 <liskin> elonsroadster[m]: To which you reacted by adding the support for recompilation, without any attempt to document it.
20:12:57 <elonsroadster[m]> In any case, to be clear, I am not against documenting anything here.
20:13:44 <elonsroadster[m]> It's just that it takes time to do something like that, especially if you want to do it well.
20:14:17 <elonsroadster[m]> It's actually something that I already started working on.
20:14:31 <liskin> Indeed, that bit I understand very much. :-)
20:14:51 <liskin> If you felt any sort of (time) pressure, that was not intended.
20:14:56 <elonsroadster[m]> That said, the idea that a "flake.nix" needs to be documented is a tiny bit strange.
20:15:23 <elonsroadster[m]> like would you say that we need to document a stack.yaml file ITSELF?
20:15:54 <elonsroadster[m]> Essentially, the how to use the flake is the same as the how to use any flake.
20:18:50 <liskin> Well we happen to document how one obtains a stack.yaml suitable for compiling xmonad from git. Obviously documenting anything more about stack.yamls is nonsensical in our context.
20:19:24 <liskin> If it is indeed as trivial to use a nix flake as it is to apt install stuff, then documenting how to use the nix flake is unnecessary.
20:20:14 <elonsroadster[m]> Right, but in the case of nix, the officially recommended way of installing xmonad is still going to be to use the nixpkgs service, which despite what you seem to believe about nix, is actually quite well documented (see https://github.com/NixOS/nixpkgs/blob/2260ac51eae29a6405054d6ec0177464de01a2bf/nixos/modules/services/x11/window-managers/xmonad.nix#L82)
20:20:21 <liskin> I was under the impression nix flakes are somewhat new, and not really the most common method of installing stuff in NixOS, but I know next to nothing about that stuff.
20:22:08 <elonsroadster[m]> liskin: yes, that is correct, what this flake is mostly providing is
20:22:08 <elonsroadster[m]> - a nix way to hack on things (in this case the usage is just nix build/ nix develop as it is with all flakes)
20:22:08 <elonsroadster[m]> - An overlay that can be used together with nixpkgs to use the master version (insted of what is on hackage)
20:22:34 <elonsroadster[m]> both of those use cases are already standard and well documented in the nix community. There is nothing special about the xmonad flake in this respect.
20:49:56 <liskin> Well, you make a quite convincing case that nothing needs to be documented. :-)
20:52:33 <liskin> On the other hand, in my Python projects I do document the installation methods so that even complete dummies who just bootem from an Ubuntu usb stick for the first can follow them, even though it could be argued that installation of Python packages is fairly standard, too. (On the other hand, the target audience there is very different there.)
20:52:45 <liskin> Too much other hands, crap.
20:54:12 <liskin> Anyway, what I'm trying to say, more documentation than you think is needed is usually nice. I know writing good docs is hard. Took me decades to learn to write READMEs in my projects.
20:54:24 <geekosaur> tbqh xmonad is not really for such users
20:54:55 <geekosaur> tiling window managers are sort of an advanced user niche
20:55:09 <liskin> So I'd still argue that the things you've said here, like https://libera.ems.host/_matrix/media/r0/download/libera.chat/f676643b5f8f1d4badfe72de2225e432cdcd730a, might actually be useful to have somewhere in the xmonad repo.
20:55:16 <geekosaur> and haskell is already a pretty high bar even if you don't learn it (installing ghc, etc.)
20:56:53 <liskin> It is, but I also feel the bar is actually getting higher with passing years, and that's not really a good thing :-/
20:57:32 <liskin> Back in 2009, all one needed really was cabal install xmonad xmonad-contrib
20:58:26 <liskin> Or maybe that's not relevant, apt install xmonad replaces that.
21:00:54 <geekosaur> some of that is the external bar being raised, by cabal and stack taking over
21:01:12 <geekosaur> one really doesn't install things "globally" any more
21:49:43 × nomadxx3 quits (~lanomadx@180-150-32-38.b49620.mel.static.aussiebb.net) (Ping timeout: 265 seconds)
22:13:09 abhixec joins (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net)
22:13:19 nomadxx3 joins (~lanomadx@69.167.38.229)
22:19:52 × seschwar quits (~seschwar@user/seschwar) (Quit: :wq)
22:23:42 cjb joins (~cjbayliss@user/cjb)
22:25:54 × geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
22:28:09 geekosaur joins (~geekosaur@xmonad/geekosaur)
22:36:14 <elonsroadster[m]> <liskin> "It is, but I also feel the bar..." <- If you're actually concerned about that, i think you should seriously consider at least stopping the denigration of nix -- It should be possible, to make it so that it is possible to get xmonad working (including even all non-haskell dependencies) with two commands and an appropriate template
22:37:26 <liskin> elonsroadster[m]: That is a good point, I'll consider it.
22:37:31 <elonsroadster[m]> <geekosaur> "tbqh xmonad is not really for..." <- I mostly agree with this take, but I have seen more and more relatively green users trying to learn xmonad. I'm not really sure it is smart to throw our hands up/just turn them away
22:38:07 <geekosaur> well, originally xmonad assumed quite a bit of unix/x11 knowledge to get started
22:38:37 <elonsroadster[m]> <liskin> "Anyway, what I'm trying to say..." <- Right i honestly mostly agree with you here, but the changes I have been making have mostly been just to serve my own interests
22:38:41 <geekosaur> and it still shows in places, like the (now old) DynamicLog stuff which assumes you understand how pipe IPC works
22:39:05 <elonsroadster[m]> geekosaur: Well thats part of why i hate the way xmobar does things
22:40:00 <liskin> Although I might need a reminder: have I actually spoken against Nix somewhere apart from the comment about documentation? I did mention numerous times that I'm clueless about Nix and that I am reluctant to actually try it myself for reasons, but did I actually say more bad things about it somewhere?
22:40:06 <elonsroadster[m]> requiring direct communication between the WM and status bar is an anti-pattern
22:41:22 <elonsroadster[m]> liskin: Mostly just that it lacks documentation several times. I really don't personally care very much -- I'm going to continue using it and thinking its a superior way to do things regardless of what anyone says.
22:41:26 <geekosaur> that's mostly xmonad's fault because of DynamicLog
22:42:07 <geekosaur> which iirc predates rwmh, which is why ManageDocks is separate from EWMH and does things like also managing desktop windows
22:42:48 <liskin> elonsroadster[m]: Hmm, I'd almost tend to think that there were other people here mentioning Nix documentation and you might be attributing all that to me, but… probably not worth digging into really. :-)
22:43:04 <elonsroadster[m]> right, but the question to me is why xmobar still mostly uses these tactics
22:43:18 <elonsroadster[m]> or can you now use xmobar with EWMH?
22:43:34 <geekosaur> not yet
22:43:53 <geekosaur> but there are xmonad-specific things that EWMH doesn't really cover in DynamicLog
22:45:01 <geekosaur> in particular, EWMH assumes a workspace covers all monitors and doesn't at all well handle xmonad's workspace implementation
22:45:04 <elonsroadster[m]> geekosaur: like what? Seems like it might be possible to signal about these things using other x propetires
22:45:25 <elonsroadster[m]> geekosaur: Right, this is fixed in taffybar with an additional module called "PagerHints"
22:46:33 <elonsroadster[m]> at least w.r.t. signaling what the current workspace status is (since it exports a notion of visible, but not focused workspace)
22:49:08 <elonsroadster[m]> liskin: At this point what would make you happy w.r.t. documentation.
22:49:40 <liskin> Why is it so bad to construct the status bar content in the WM, though? The pipe is obviously shit, but if it goes through X props, the flexibility of doing it in xmonad seems often worth it.
22:51:42 <elonsroadster[m]> liskin: A bunch of reasons:
22:52:00 <liskin> elonsroadster[m]: If I may be honest, at this point I'd prefer if you made these two guys: https://github.com/xmonad/xmonad/pull/330#issuecomment-917667883 https://github.com/xmonad/xmonad/pull/330#issuecomment-917833838 happy, because I could use a break from this stuff :-)
22:52:09 <elonsroadster[m]> - If you restart the status bar frequently you need to figure out how to restore the connections to the wm every time
22:52:47 <elonsroadster[m]> - What if you are using multi-head and you want to have disparate content on each of screens?
22:52:56 <liskin> (and when I say make them happy I don't necessarily mean to do exactly what they say in those comments—it does sound sensible to me, but I also trust them to have good judgement, so whatever else makes them happy makes me happy too)
22:53:19 <elonsroadster[m]> - Couples the bar very tightly to xmonad in an unnecessary way
22:53:50 <elonsroadster[m]> - only really allows text content
22:53:58 <liskin> Oh but you only talk about the "pipe is obviously shit" bit, which I absolutely agree with, but that's been a solved problem since 2010 or whenever
22:54:42 <liskin> Although we only properly documented and abstracted the stuff recently, and xmobar still needs non-default configuration to use X props
22:54:50 <liskin> So yeah it's not really a solved problem.
22:55:02 <liskin> It was a "works for me" kind of solved problem since 2010. :-)
22:55:18 <elonsroadster[m]> sure, I mean your question was "Why is it so bad to construct the status bar content in the WM, though?"
22:55:37 <elonsroadster[m]> it also just offends my sensibilities
22:55:51 <liskin> Yes, exactly, "construct the content", regardless of how you transfer that content to xmobar.
22:56:12 <liskin> So that leaves us with "only really allows text content", which is kind of a limitation of xmobar in general :-)
22:56:19 <elonsroadster[m]> I think the last 3 still apply no?
22:56:42 <liskin> Last 2, multi-head works with X props fine
22:57:19 <geekosaur> I'd like to point out that there's no sane way to do https://github.com/geekosaur/xmonad.hs/blob/pyanfar/xmonad.hs#L261-L279 if I can't construct it in xmonad
22:57:41 <geekosaur> because it'd be an even bigger hack to do it in the status bar
22:57:48 × abhixec quits (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Ping timeout: 268 seconds)
22:57:58 <geekosaur> (especially for me since I'm logging to an xmonad-log-applet in mate-panel)
22:58:08 <liskin> The tight coupling is a tradeoff, I'd say. I quite like having direct access to all xmonad state when constructing the status bar content, but I can very well imagine that one might instead want to just read from EWMH in an xmobar plugin and do some theming there.
22:58:38 <liskin> Having both options is fine, IMHO.
22:58:46 <liskin> (Now we only have one, yes.)
22:58:51 <elonsroadster[m]> I mean i think ewmh is not really that great either
22:59:03 <elonsroadster[m]> id love to see a dbus standard
22:59:20 <elonsroadster[m]> that would allow things to even be X/Wayland agnostic
22:59:34 <elonsroadster[m]> geekosaur: What exactly is that doing?
23:00:24 <geekosaur> showing the visible workspaces, which one is active, and also showing any workspace(s) with urgent-hint windows
23:00:27 <elonsroadster[m]> liskin: what xmonad state are you actually using though? Just curious?
23:00:57 <elonsroadster[m]> geekosaur: taffybar does all of this... and even shows you individually which WINDOW has the urgency hint
23:01:39 <geekosaur> but I'm already running mate-paneland don't want another status bar
23:02:11 <elonsroadster[m]> geekosaur: sure, that's fine. I'm just saying it is entirely possible to do those things outside of xmonad
23:02:46 <elonsroadster[m]> you can make calls to the xserver to get any information that xmonad also has (except maybe for layout information about workspaces that are not currently displayed)
23:03:21 <liskin> elonsroadster[m]: apart from the usual stuff that's in PP, titles of all windows (like a hardstatus in screen/tmux), titles of urgent windows (those go on the primary xmobar), titles of weechat windows (so that I see the hotlist wherever I am), dnd status (so that I don't see the hotlist, lol), sublayout groups (so that the hardstatus shows the same number as keybindings for windows switching)
23:03:31 <liskin> possibly something else I may have forgotten
23:04:14 <liskin> my xmobars are packed full of shit, and I literally have to use nerdfonts/fontawesome to compress common words into icons
23:04:14 <elonsroadster[m]> liskin: All of that is information that the X server has though... There's no need to relay through the window manager, right?
23:05:06 <liskin> elonsroadster[m]: sublayout groups would be hard to access and dnd is fairly custom but can be written into a property
23:05:07 <elonsroadster[m]> liskin: Right, this is why text only is shit. Icons are pretty useful in certain contexts.
23:05:48 <liskin> but yeah, if I tried really hard, I might make xmobar display all of that by itself
23:06:03 <liskin> why would I, though :-)
23:07:01 <liskin> I have bash scripts pushing content to xmobar through X props here
23:07:27 <elonsroadster[m]> liskin: To each their own, sounds like it works great for you. To me this sort of design feels like its held together by string and ducktape.
23:07:42 <geekosaur> that *is* the unix philosophy
23:07:52 <liskin> elonsroadster[m]: it is most certainly not strongly typed :-)
23:08:02 <elonsroadster[m]> geekosaur: hard disagree. Unix philosophy is about composability
23:08:35 <elonsroadster[m]> in fact, i would argue its kind of antithetical to the unix philosophy. The idea of unix is that different commands should be composable, but not that they should know who/what they are composing with
23:11:04 <elonsroadster[m]> "Write programs that do one thing and do it well." but in this case, xmobar is sort of a weird Siamese twin of xmonad, that cant exist independently very well, and xmonad handles some of its responsibilities.
23:12:31 <liskin> it's a bit of that, yes
23:12:53 <liskin> before xmobar there was dzen, and that literally only did one thing: read lines from stdin and showed them in the bar
23:13:21 <liskin> xmobar tries to do more, like date and weather and cpu and battery, but not workspaces/windows
23:14:33 <liskin> it does fill a niche, though :-)
23:22:43 <liskin> Anyway, I'm going to head to bed. If I offend/insult you again, please do chat to me here to clear it up, I'd hate to drive people away. Good night.
23:45:54 <davve> im loving polybar

All times are in UTC on 2021-09-13.