Logs: liberachat/#xmonad
| 2021-09-13 20:14:56 | <elonsroadster[m]> | That said, the idea that a "flake.nix" needs to be documented is a tiny bit strange. |
| 2021-09-13 20:15:23 | <elonsroadster[m]> | like would you say that we need to document a stack.yaml file ITSELF? |
| 2021-09-13 20:15:54 | <elonsroadster[m]> | Essentially, the how to use the flake is the same as the how to use any flake. |
| 2021-09-13 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. |
| 2021-09-13 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. |
| 2021-09-13 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) |
| 2021-09-13 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. |
| 2021-09-13 20:22:08 | <elonsroadster[m]> | liskin: yes, that is correct, what this flake is mostly providing is |
| 2021-09-13 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) |
| 2021-09-13 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) |
| 2021-09-13 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. |
| 2021-09-13 20:49:56 | <liskin> | Well, you make a quite convincing case that nothing needs to be documented. :-) |
| 2021-09-13 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.) |
| 2021-09-13 20:52:45 | <liskin> | Too much other hands, crap. |
| 2021-09-13 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. |
| 2021-09-13 20:54:24 | <geekosaur> | tbqh xmonad is not really for such users |
| 2021-09-13 20:54:55 | <geekosaur> | tiling window managers are sort of an advanced user niche |
| 2021-09-13 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. |
| 2021-09-13 20:55:16 | <geekosaur> | and haskell is already a pretty high bar even if you don't learn it (installing ghc, etc.) |
| 2021-09-13 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 :-/ |
| 2021-09-13 20:57:32 | <liskin> | Back in 2009, all one needed really was cabal install xmonad xmonad-contrib |
| 2021-09-13 20:58:26 | <liskin> | Or maybe that's not relevant, apt install xmonad replaces that. |
| 2021-09-13 21:00:54 | <geekosaur> | some of that is the external bar being raised, by cabal and stack taking over |
| 2021-09-13 21:01:12 | <geekosaur> | one really doesn't install things "globally" any more |
| 2021-09-13 21:49:43 | × | nomadxx3 quits (~lanomadx@180-150-32-38.b49620.mel.static.aussiebb.net) (Ping timeout: 265 seconds) |
| 2021-09-13 22:13:09 | → | abhixec joins (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) |
| 2021-09-13 22:13:19 | → | nomadxx3 joins (~lanomadx@69.167.38.229) |
| 2021-09-13 22:19:52 | × | seschwar quits (~seschwar@user/seschwar) (Quit: :wq) |
| 2021-09-13 22:23:42 | → | cjb joins (~cjbayliss@user/cjb) |
| 2021-09-13 22:25:54 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-09-13 22:28:09 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2021-09-13 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 |
| 2021-09-13 22:37:26 | <liskin> | elonsroadster[m]: That is a good point, I'll consider it. |
| 2021-09-13 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 |
| 2021-09-13 22:38:07 | <geekosaur> | well, originally xmonad assumed quite a bit of unix/x11 knowledge to get started |
| 2021-09-13 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 |
| 2021-09-13 22:38:41 | <geekosaur> | and it still shows in places, like the (now old) DynamicLog stuff which assumes you understand how pipe IPC works |
| 2021-09-13 22:39:05 | <elonsroadster[m]> | geekosaur: Well thats part of why i hate the way xmobar does things |
| 2021-09-13 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? |
| 2021-09-13 22:40:06 | <elonsroadster[m]> | requiring direct communication between the WM and status bar is an anti-pattern |
| 2021-09-13 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. |
| 2021-09-13 22:41:26 | <geekosaur> | that's mostly xmonad's fault because of DynamicLog |
| 2021-09-13 22:42:07 | <geekosaur> | which iirc predates rwmh, which is why ManageDocks is separate from EWMH and does things like also managing desktop windows |
| 2021-09-13 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. :-) |
| 2021-09-13 22:43:04 | <elonsroadster[m]> | right, but the question to me is why xmobar still mostly uses these tactics |
| 2021-09-13 22:43:18 | <elonsroadster[m]> | or can you now use xmobar with EWMH? |
| 2021-09-13 22:43:34 | <geekosaur> | not yet |
| 2021-09-13 22:43:53 | <geekosaur> | but there are xmonad-specific things that EWMH doesn't really cover in DynamicLog |
| 2021-09-13 22:45:01 | <geekosaur> | in particular, EWMH assumes a workspace covers all monitors and doesn't at all well handle xmonad's workspace implementation |
| 2021-09-13 22:45:04 | <elonsroadster[m]> | geekosaur: like what? Seems like it might be possible to signal about these things using other x propetires |
| 2021-09-13 22:45:25 | <elonsroadster[m]> | geekosaur: Right, this is fixed in taffybar with an additional module called "PagerHints" |
| 2021-09-13 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) |
| 2021-09-13 22:49:08 | <elonsroadster[m]> | liskin: At this point what would make you happy w.r.t. documentation. |
| 2021-09-13 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. |
| 2021-09-13 22:51:42 | <elonsroadster[m]> | liskin: A bunch of reasons: |
| 2021-09-13 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 :-) |
| 2021-09-13 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 |
| 2021-09-13 22:52:47 | <elonsroadster[m]> | - What if you are using multi-head and you want to have disparate content on each of screens? |
| 2021-09-13 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) |
| 2021-09-13 22:53:19 | <elonsroadster[m]> | - Couples the bar very tightly to xmonad in an unnecessary way |
| 2021-09-13 22:53:50 | <elonsroadster[m]> | - only really allows text content |
| 2021-09-13 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 |
| 2021-09-13 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 |
| 2021-09-13 22:54:50 | <liskin> | So yeah it's not really a solved problem. |
| 2021-09-13 22:55:02 | <liskin> | It was a "works for me" kind of solved problem since 2010. :-) |
| 2021-09-13 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?" |
| 2021-09-13 22:55:37 | <elonsroadster[m]> | it also just offends my sensibilities |
| 2021-09-13 22:55:51 | <liskin> | Yes, exactly, "construct the content", regardless of how you transfer that content to xmobar. |
| 2021-09-13 22:56:12 | <liskin> | So that leaves us with "only really allows text content", which is kind of a limitation of xmobar in general :-) |
| 2021-09-13 22:56:19 | <elonsroadster[m]> | I think the last 3 still apply no? |
| 2021-09-13 22:56:42 | <liskin> | Last 2, multi-head works with X props fine |
| 2021-09-13 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 |
| 2021-09-13 22:57:41 | <geekosaur> | because it'd be an even bigger hack to do it in the status bar |
| 2021-09-13 22:57:48 | × | abhixec quits (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Ping timeout: 268 seconds) |
| 2021-09-13 22:57:58 | <geekosaur> | (especially for me since I'm logging to an xmonad-log-applet in mate-panel) |
| 2021-09-13 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. |
| 2021-09-13 22:58:38 | <liskin> | Having both options is fine, IMHO. |
| 2021-09-13 22:58:46 | <liskin> | (Now we only have one, yes.) |
| 2021-09-13 22:58:51 | <elonsroadster[m]> | I mean i think ewmh is not really that great either |
| 2021-09-13 22:59:03 | <elonsroadster[m]> | id love to see a dbus standard |
| 2021-09-13 22:59:20 | <elonsroadster[m]> | that would allow things to even be X/Wayland agnostic |
| 2021-09-13 22:59:34 | <elonsroadster[m]> | geekosaur: What exactly is that doing? |
| 2021-09-13 23:00:24 | <geekosaur> | showing the visible workspaces, which one is active, and also showing any workspace(s) with urgent-hint windows |
| 2021-09-13 23:00:27 | <elonsroadster[m]> | liskin: what xmonad state are you actually using though? Just curious? |
| 2021-09-13 23:00:57 | <elonsroadster[m]> | geekosaur: taffybar does all of this... and even shows you individually which WINDOW has the urgency hint |
| 2021-09-13 23:01:39 | <geekosaur> | but I'm already running mate-paneland don't want another status bar |
| 2021-09-13 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 |
| 2021-09-13 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) |
| 2021-09-13 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) |
| 2021-09-13 23:03:31 | <liskin> | possibly something else I may have forgotten |
| 2021-09-13 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 |
| 2021-09-13 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? |
| 2021-09-13 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 |
| 2021-09-13 23:05:07 | <elonsroadster[m]> | liskin: Right, this is why text only is shit. Icons are pretty useful in certain contexts. |
| 2021-09-13 23:05:48 | <liskin> | but yeah, if I tried really hard, I might make xmobar display all of that by itself |
| 2021-09-13 23:06:03 | <liskin> | why would I, though :-) |
| 2021-09-13 23:07:01 | <liskin> | I have bash scripts pushing content to xmobar through X props here |
| 2021-09-13 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. |
| 2021-09-13 23:07:42 | <geekosaur> | that *is* the unix philosophy |
| 2021-09-13 23:07:52 | <liskin> | elonsroadster[m]: it is most certainly not strongly typed :-) |
All times are in UTC.