| 2021-09-14 00:13:09 +0200 | abhixec | (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) |
| 2021-09-14 00:13:19 +0200 | nomadxx3 | (~lanomadx@69.167.38.229) |
| 2021-09-14 00:19:52 +0200 | seschwar | (~seschwar@user/seschwar) (Quit: :wq) |
| 2021-09-14 00:23:42 +0200 | cjb | (~cjbayliss@user/cjb) |
| 2021-09-14 00:25:54 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-09-14 00:28:09 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-09-14 00:36:14 +0200 | <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 |
| 2021-09-14 00:37:26 +0200 | <liskin> | elonsroadster[m]: That is a good point, I'll consider it. |
| 2021-09-14 00:37:31 +0200 | <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 |
| 2021-09-14 00:38:07 +0200 | <geekosaur> | well, originally xmonad assumed quite a bit of unix/x11 knowledge to get started |
| 2021-09-14 00:38:37 +0200 | <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 |
| 2021-09-14 00:38:41 +0200 | <geekosaur> | and it still shows in places, like the (now old) DynamicLog stuff which assumes you understand how pipe IPC works |
| 2021-09-14 00:39:05 +0200 | <elonsroadster[m]> | geekosaur: Well thats part of why i hate the way xmobar does things |
| 2021-09-14 00:40:00 +0200 | <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? |
| 2021-09-14 00:40:06 +0200 | <elonsroadster[m]> | requiring direct communication between the WM and status bar is an anti-pattern |
| 2021-09-14 00:41:22 +0200 | <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. |
| 2021-09-14 00:41:26 +0200 | <geekosaur> | that's mostly xmonad's fault because of DynamicLog |
| 2021-09-14 00:42:07 +0200 | <geekosaur> | which iirc predates rwmh, which is why ManageDocks is separate from EWMH and does things like also managing desktop windows |
| 2021-09-14 00:42:48 +0200 | <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. :-) |
| 2021-09-14 00:43:04 +0200 | <elonsroadster[m]> | right, but the question to me is why xmobar still mostly uses these tactics |
| 2021-09-14 00:43:18 +0200 | <elonsroadster[m]> | or can you now use xmobar with EWMH? |
| 2021-09-14 00:43:34 +0200 | <geekosaur> | not yet |
| 2021-09-14 00:43:53 +0200 | <geekosaur> | but there are xmonad-specific things that EWMH doesn't really cover in DynamicLog |
| 2021-09-14 00:45:01 +0200 | <geekosaur> | in particular, EWMH assumes a workspace covers all monitors and doesn't at all well handle xmonad's workspace implementation |
| 2021-09-14 00:45:04 +0200 | <elonsroadster[m]> | geekosaur: like what? Seems like it might be possible to signal about these things using other x propetires |
| 2021-09-14 00:45:25 +0200 | <elonsroadster[m]> | geekosaur: Right, this is fixed in taffybar with an additional module called "PagerHints" |
| 2021-09-14 00:46:33 +0200 | <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) |
| 2021-09-14 00:49:08 +0200 | <elonsroadster[m]> | liskin: At this point what would make you happy w.r.t. documentation. |
| 2021-09-14 00:49:40 +0200 | <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. |
| 2021-09-14 00:51:42 +0200 | <elonsroadster[m]> | liskin: A bunch of reasons: |
| 2021-09-14 00:52:00 +0200 | <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 :-) |
| 2021-09-14 00:52:09 +0200 | <elonsroadster[m]> | - If you restart the status bar frequently you need to figure out how to restore the connections to the wm every time |
| 2021-09-14 00:52:47 +0200 | <elonsroadster[m]> | - What if you are using multi-head and you want to have disparate content on each of screens? |
| 2021-09-14 00:52:56 +0200 | <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) |
| 2021-09-14 00:53:19 +0200 | <elonsroadster[m]> | - Couples the bar very tightly to xmonad in an unnecessary way |
| 2021-09-14 00:53:50 +0200 | <elonsroadster[m]> | - only really allows text content |
| 2021-09-14 00:53:58 +0200 | <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 |
| 2021-09-14 00:54:42 +0200 | <liskin> | Although we only properly documented and abstracted the stuff recently, and xmobar still needs non-default configuration to use X props |
| 2021-09-14 00:54:50 +0200 | <liskin> | So yeah it's not really a solved problem. |
| 2021-09-14 00:55:02 +0200 | <liskin> | It was a "works for me" kind of solved problem since 2010. :-) |
| 2021-09-14 00:55:18 +0200 | <elonsroadster[m]> | sure, I mean your question was "Why is it so bad to construct the status bar content in the WM, though?" |
| 2021-09-14 00:55:37 +0200 | <elonsroadster[m]> | it also just offends my sensibilities |
| 2021-09-14 00:55:51 +0200 | <liskin> | Yes, exactly, "construct the content", regardless of how you transfer that content to xmobar. |
| 2021-09-14 00:56:12 +0200 | <liskin> | So that leaves us with "only really allows text content", which is kind of a limitation of xmobar in general :-) |
| 2021-09-14 00:56:19 +0200 | <elonsroadster[m]> | I think the last 3 still apply no? |
| 2021-09-14 00:56:42 +0200 | <liskin> | Last 2, multi-head works with X props fine |
| 2021-09-14 00:57:19 +0200 | <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 |
| 2021-09-14 00:57:41 +0200 | <geekosaur> | because it'd be an even bigger hack to do it in the status bar |
| 2021-09-14 00:57:48 +0200 | abhixec | (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Ping timeout: 268 seconds) |
| 2021-09-14 00:57:58 +0200 | <geekosaur> | (especially for me since I'm logging to an xmonad-log-applet in mate-panel) |
| 2021-09-14 00:58:08 +0200 | <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. |
| 2021-09-14 00:58:38 +0200 | <liskin> | Having both options is fine, IMHO. |
| 2021-09-14 00:58:46 +0200 | <liskin> | (Now we only have one, yes.) |
| 2021-09-14 00:58:51 +0200 | <elonsroadster[m]> | I mean i think ewmh is not really that great either |
| 2021-09-14 00:59:03 +0200 | <elonsroadster[m]> | id love to see a dbus standard |
| 2021-09-14 00:59:20 +0200 | <elonsroadster[m]> | that would allow things to even be X/Wayland agnostic |
| 2021-09-14 00:59:34 +0200 | <elonsroadster[m]> | geekosaur: What exactly is that doing? |
| 2021-09-14 01:00:24 +0200 | <geekosaur> | showing the visible workspaces, which one is active, and also showing any workspace(s) with urgent-hint windows |
| 2021-09-14 01:00:27 +0200 | <elonsroadster[m]> | liskin: what xmonad state are you actually using though? Just curious? |
| 2021-09-14 01:00:57 +0200 | <elonsroadster[m]> | geekosaur: taffybar does all of this... and even shows you individually which WINDOW has the urgency hint |
| 2021-09-14 01:01:39 +0200 | <geekosaur> | but I'm already running mate-paneland don't want another status bar |
| 2021-09-14 01:02:11 +0200 | <elonsroadster[m]> | geekosaur: sure, that's fine. I'm just saying it is entirely possible to do those things outside of xmonad |
| 2021-09-14 01:02:46 +0200 | <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) |
| 2021-09-14 01:03:21 +0200 | <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) |
| 2021-09-14 01:03:31 +0200 | <liskin> | possibly something else I may have forgotten |
| 2021-09-14 01:04:14 +0200 | <liskin> | my xmobars are packed full of shit, and I literally have to use nerdfonts/fontawesome to compress common words into icons |
| 2021-09-14 01:04:14 +0200 | <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? |
| 2021-09-14 01:05:06 +0200 | <liskin> | elonsroadster[m]: sublayout groups would be hard to access and dnd is fairly custom but can be written into a property |
| 2021-09-14 01:05:07 +0200 | <elonsroadster[m]> | liskin: Right, this is why text only is shit. Icons are pretty useful in certain contexts. |
| 2021-09-14 01:05:48 +0200 | <liskin> | but yeah, if I tried really hard, I might make xmobar display all of that by itself |
| 2021-09-14 01:06:03 +0200 | <liskin> | why would I, though :-) |
| 2021-09-14 01:07:01 +0200 | <liskin> | I have bash scripts pushing content to xmobar through X props here |
| 2021-09-14 01:07:27 +0200 | <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. |
| 2021-09-14 01:07:42 +0200 | <geekosaur> | that *is* the unix philosophy |
| 2021-09-14 01:07:52 +0200 | <liskin> | elonsroadster[m]: it is most certainly not strongly typed :-) |
| 2021-09-14 01:08:02 +0200 | <elonsroadster[m]> | geekosaur: hard disagree. Unix philosophy is about composability |
| 2021-09-14 01:08:35 +0200 | <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 |
| 2021-09-14 01:11:04 +0200 | <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. |
| 2021-09-14 01:12:31 +0200 | <liskin> | it's a bit of that, yes |
| 2021-09-14 01:12:53 +0200 | <liskin> | before xmobar there was dzen, and that literally only did one thing: read lines from stdin and showed them in the bar |
| 2021-09-14 01:13:21 +0200 | <liskin> | xmobar tries to do more, like date and weather and cpu and battery, but not workspaces/windows |
| 2021-09-14 01:14:33 +0200 | <liskin> | it does fill a niche, though :-) |
| 2021-09-14 01:22:43 +0200 | <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. |
| 2021-09-14 01:45:54 +0200 | <davve> | im loving polybar |
| 2021-09-14 02:13:18 +0200 | <TheWizardTower[m> | <geekosaur> "that *is* the unix philosophy" <- I've worked in devops for over ten years. |
| 2021-09-14 02:13:18 +0200 | <TheWizardTower[m> | this is undeniably true. |
| 2021-09-14 02:57:15 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Ping timeout: 265 seconds) |
| 2021-09-14 02:58:16 +0200 | dmwit | (~dmwit@pool-173-73-185-183.washdc.fios.verizon.net) |
| 2021-09-14 03:59:31 +0200 | electr0n | (~electr0n@about/security/founder/electr0n) |
| 2021-09-14 04:03:26 +0200 | banc | (banc@gateway/vpn/airvpn/banc) (Ping timeout: 260 seconds) |
| 2021-09-14 04:22:10 +0200 | banc | (banc@gateway/vpn/airvpn/banc) |
| 2021-09-14 04:23:46 +0200 | td_ | (~td@94.134.91.92) (Ping timeout: 268 seconds) |
| 2021-09-14 04:25:17 +0200 | td_ | (~td@muedsl-82-207-238-177.citykom.de) |
| 2021-09-14 05:39:02 +0200 | thunderrd | (~thunderrd@183.182.111.67) |
| 2021-09-14 05:55:39 +0200 | thunderrd | (~thunderrd@183.182.111.67) (Ping timeout: 268 seconds) |
| 2021-09-14 06:26:40 +0200 | benin036932301 | (~benin@183.82.24.227) |
| 2021-09-14 06:27:01 +0200 | benin03693230 | (~benin@183.82.24.227) (Ping timeout: 265 seconds) |
| 2021-09-14 06:27:02 +0200 | benin036932301 | benin03693230 |
| 2021-09-14 06:27:02 +0200 | benin03693230 | (~benin@183.82.24.227) (Remote host closed the connection) |
| 2021-09-14 07:56:41 +0200 | cjb | (~cjbayliss@user/cjb) () |
| 2021-09-14 08:20:03 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2021-09-14 08:39:02 +0200 | thunderrd | (~thunderrd@183.182.111.251) |
| 2021-09-14 09:36:35 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2021-09-14 10:05:22 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-09-14 10:50:48 +0200 | tremon | (~tremon@217-63-61-89.cable.dynamic.v4.ziggo.nl) |
| 2021-09-14 10:56:06 +0200 | sagax | (~sagax_nb@user/sagax) (Read error: Connection reset by peer) |
| 2021-09-14 11:21:51 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Ping timeout: 265 seconds) |
| 2021-09-14 12:18:07 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-09-14 14:17:34 +0200 | HabibKhan[m] | (~habibkhan@2001:470:69fc:105::f5f6) |
| 2021-09-14 14:18:50 +0200 | HabibKhan[m] | (~habibkhan@2001:470:69fc:105::f5f6) () |
| 2021-09-14 14:23:18 +0200 | xmonadcool | (~xmonadcoo@5-15-55-28.residential.rdsnet.ro) |
| 2021-09-14 14:23:58 +0200 | <xmonadcool> | can someone tell me how to implement this: https://github.com/jaor/xmobar/issues/239#issuecomment-233206552 |
| 2021-09-14 14:24:06 +0200 | <xmonadcool> | im a bit confused on that |
| 2021-09-14 15:01:06 +0200 | xmonadcool | (~xmonadcoo@5-15-55-28.residential.rdsnet.ro) (Quit: Client closed) |
| 2021-09-14 15:26:12 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.2.1) |
| 2021-09-14 15:37:59 +0200 | a6a45081-2b83 | (~aditya@pal-210-106-57.itap.purdue.edu) |
| 2021-09-14 15:42:15 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-09-14 15:45:02 +0200 | Digit | (~user@user/digit) (Ping timeout: 252 seconds) |
| 2021-09-14 16:19:23 +0200 | a6a45081-2b83 | (~aditya@pal-210-106-57.itap.purdue.edu) (Remote host closed the connection) |
| 2021-09-14 17:03:15 +0200 | dexterfoo | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) (Quit: WeeChat 1.9.1) |
| 2021-09-14 17:32:39 +0200 | Solid | also handed in his thesis today |
| 2021-09-14 17:32:53 +0200 | <liskin> | party time! |
| 2021-09-14 17:33:20 +0200 | <Solid> | now I'm free to write all of the emacs latex packages; fixing issues that were bugging me while writing this :D |
| 2021-09-14 17:40:13 +0200 | <mc47> | Congrats Solid! |
| 2021-09-14 17:42:31 +0200 | <geekosaur> | congratulations! |
| 2021-09-14 17:49:28 +0200 | mc47 | had to resubmit his today, because he forgot to sign it |
| 2021-09-14 17:52:37 +0200 | seschwar | (~seschwar@user/seschwar) |
| 2021-09-14 17:55:08 +0200 | <Solid> | thank you people :) |
| 2021-09-14 18:04:27 +0200 | <liskin> | elonsroadster[m]: apparently someone's trying to tie xmobar even tighter with xmonad: https://github.com/jaor/xmobar/issues/567 :-)) |
| 2021-09-14 18:04:42 +0200 | <liskin> | tldr run it as a thread in xmonad's process |
| 2021-09-14 18:04:55 +0200 | <liskin> | that's one way to deal with restarting of xmobars, I guess :-)) |
| 2021-09-14 18:05:51 +0200 | <liskin> | (there are probably good reasons not to do it because of how we approach signals and thread in xmonad, but it's certainly a fun exercise) |
| 2021-09-14 18:06:39 +0200 | <geekosaur> | and events in general; we don't handle timed events, for example |
| 2021-09-14 18:06:57 +0200 | <liskin> | well that's not a problem here |
| 2021-09-14 18:07:02 +0200 | <geekosaur> | there's a hack but there's also several contrib bugs involving them |
| 2021-09-14 18:07:44 +0200 | <liskin> | but the signal handling will interfere between the two "main"s |
| 2021-09-14 18:08:01 +0200 | <liskin> | and the shared use of xlib might possibly too |
| 2021-09-14 18:08:45 +0200 | <geekosaur> | shared xlib is mostly safe as long as you don't inadvertently mix the two up |
| 2021-09-14 18:30:41 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.2.1) |
| 2021-09-14 20:11:35 +0200 | thunderrd | (~thunderrd@183.182.111.251) (Ping timeout: 265 seconds) |
| 2021-09-14 21:17:53 +0200 | electr0n | (~electr0n@about/security/founder/electr0n) (Quit: WeeChat 3.2) |
| 2021-09-14 21:54:12 +0200 | electr0n | (~electr0n@about/security/founder/electr0n) |
| 2021-09-14 22:41:49 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-09-14 22:42:14 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-09-14 23:02:40 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2021-09-14 23:19:10 +0200 | seschwar | (~seschwar@user/seschwar) (Quit: :wq) |