Logs: liberachat/#xmonad
| 2021-11-14 16:33:34 | <geekosaur> | yeh, the combinator is an all-in-one solution |
| 2021-11-14 16:33:47 | <geekosaur> | and now you need xmobar configured with a StdinReader |
| 2021-11-14 16:34:23 | <geekosaur> | otherwise the pipe will eventually fill up and xmonad will block. (0.17.0 provides a different setup based on X properties, which won't block) |
| 2021-11-14 16:34:45 | <noex> | oh really |
| 2021-11-14 16:35:13 | <noex> | woah, yeah mine is pretty outdated |
| 2021-11-14 16:35:15 | <noex> | wth |
| 2021-11-14 16:35:29 | <geekosaur> | that's why I pointed to X.H.StatusBar earlier. it's a somewhat easier configuration that uses properties instead of pipes, so it behaves somewhat better |
| 2021-11-14 16:35:43 | <noex> | apparently gentoo provides 0.15 |
| 2021-11-14 16:36:01 | <geekosaur> | hm, thought they'd upgraded :( |
| 2021-11-14 16:36:09 | <geekosaur> | 0.17.0 was only released a week ago |
| 2021-11-14 16:36:22 | <noex> | might be a pr for it. i'll yell about it :) |
| 2021-11-14 16:36:25 | <geekosaur> | guess you would have to get it from hackage |
| 2021-11-14 16:37:11 | <geekosaur> | well, it's not uncommon that distributions take their cue from stackage. and stackage is blocked on updates because of recent ghc upgrades (nightly is not yet usable, so no new LTS) |
| 2021-11-14 16:37:43 | <noex> | ahh yeah, i tried to build ghc from source for a school project and they had other outdated packages I noticed |
| 2021-11-14 16:38:27 | <noex> | i should really support this project monetarily. xmonad is the most important tool i have. i would really hate to have to use anything else. |
| 2021-11-14 16:39:06 | <noex> | i'm totally sponsoring this project on gh |
| 2021-11-14 16:39:18 | <geekosaur> | hm, stackage nightly still on 9.0.1. which a lot of folks are skipping because 9.0.1 is buggy :( |
| 2021-11-14 16:39:38 | <geekosaur> | this seems a bit counterproductive |
| 2021-11-14 16:40:25 | <geekosaur> | in particular few packages intend to update for compatibility until either 9.0.2 comes out or stackage commits to 9.2.1 |
| 2021-11-14 16:41:20 | <noex> | i know at work i had to set everything up using cabal because RHEL and CentOS didn't provide xmonad for version 8 yet |
| 2021-11-14 16:41:28 | <noex> | probably had much newer packages than other distros that way |
| 2021-11-14 16:42:11 | <noex> | and by that i mean EPEL |
| 2021-11-14 16:42:16 | <obimod> | <3 xmonad |
| 2021-11-14 16:42:16 | <geekosaur> | at least nightly now has 0.17.0 |
| 2021-11-14 16:42:35 | <obimod> | so much better than any other window manager i've used |
| 2021-11-14 16:43:12 | <noex> | it really is the greatest |
| 2021-11-14 16:43:36 | <noex> | when i had a mac at work, i found some plugin to make it attempt to behave like xmonad, but it wasn't the same at all |
| 2021-11-14 16:46:17 | <geekosaur> | apple makes it really difficult to do that :( |
| 2021-11-14 16:47:07 | <geekosaur> | there have been several attempts, including at least one attempted port of xmonad itself, but apple doesn't provide enough hooks and they randomly change stuff whenever they feel like it |
| 2021-11-14 16:47:49 | <geekosaur> | (hm, was osxmonad a port or a rewrite? don't recall any more) |
| 2021-11-14 16:48:05 | <obimod> | there's amethyst |
| 2021-11-14 16:48:19 | <obimod> | it has improved but you can tell something at the core cannot be done |
| 2021-11-14 16:48:25 | <obimod> | osx windows are just too heavy imo |
| 2021-11-14 16:48:31 | <obimod> | at least that's how it feels |
| 2021-11-14 16:48:44 | <noex> | i used something called Amethyst. I applaud the dev's efforts, but yeah...just not the same |
| 2021-11-14 16:48:55 | <obimod> | and by osx windows i mean osx windowing management |
| 2021-11-14 16:49:02 | <geekosaur> | they work completely differently from x11 windows |
| 2021-11-14 16:49:27 | <obimod> | xmonad is like community college, it's just what you need |
| 2021-11-14 16:49:33 | <geekosaur> | and libapplewm provides too few hooks, in part because too much is controlled by the window itself in the apple model |
| 2021-11-14 16:49:34 | <obimod> | a (good) community college :) |
| 2021-11-14 16:49:50 | <geekosaur> | (and the windows model, for that matter, which is why nobody's tried to port xmonad to windows) |
| 2021-11-14 16:52:33 | → | alternateved joins (~user@staticline-31-183-149-3.toya.net.pl) |
| 2021-11-14 16:52:40 | <noex> | oh windows |
| 2021-11-14 16:53:08 | <noex> | :) |
| 2021-11-14 16:53:37 | <geekosaur> | like, you can't make the titlebar and buttons go away because they're rendered by the application (toolkit), not the system |
| 2021-11-14 16:54:22 | <geekosaur> | which makes them more flexible for the application but means you can't really do "minimalist" |
| 2021-11-14 16:58:06 | <noex> | yeah the word "minimalist" doesn't seem to be in microsoft's vocabulary |
| 2021-11-14 16:59:39 | <noex> | i had to automate some package installs at work and it was basically a game of "let's find which non-standard flag I need to pass this one to make it not pop up a gui" |
| 2021-11-14 17:00:36 | <noex> | it just really seems to fight automation and simplicity |
| 2021-11-14 17:03:32 | <geekosaur> | what I have never understood about mswindows is, how is microsoft itself not affected by this? |
| 2021-11-14 17:03:59 | <noex> | lol |
| 2021-11-14 17:04:00 | <geekosaur> | you'd think they would want to automate building things themselves, especially these days |
| 2021-11-14 17:04:50 | <noex> | yeah, idk that's a good question. maybe some proprietary in-house tools |
| 2021-11-14 17:06:42 | <noex> | the lack of thought that goes into some things is really mind blowing. i tried to embrace powershell remoting because it worked almost out of the box at work, until I realized they had not considered editing files. after googling extensively, the best solution I found is you have to basically just cat and echo into files. |
| 2021-11-14 17:09:12 | <geekosaur> | well, I think in the older days they just did it once and made a system image they could slap around. but that doesn't scale to the cloud very well unless they've also reinvented something like docker — but mswindows doesn't make that easy either |
| 2021-11-14 17:10:39 | <obimod> | i don't know haskell and i think i might be missing something obvious here; but xmobar is not instantiating multiple instances across screens. does anyone know what i'm missing? think the relevent config is here: https://dpaste.org/FSb2#L392,393,397,402 |
| 2021-11-14 17:16:07 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-11-14 17:16:32 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2021-11-14 17:19:27 | <geekosaur> | not seeing anything obviously wrong, unless xmobar needs the -x option before the config file |
| 2021-11-14 17:19:54 | <noex> | mine is only on one screen as well, but I'm okay with that |
| 2021-11-14 17:20:17 | <noex> | must be the default? |
| 2021-11-14 17:20:46 | <geekosaur> | default is it places itself on screen 0. -x option lets you specify a screen |
| 2021-11-14 17:23:26 | <obimod> | -x option on line 393 -- yea, this is definitely a nice to have. essentially procrastination from other things |
| 2021-11-14 17:23:45 | <obimod> | i'm fine with it on only one screen |
| 2021-11-14 17:24:07 | <obimod> | i did learn to send xmobar SIGUSR1 to change screens |
| 2021-11-14 17:24:12 | <obimod> | that was nice |
| 2021-11-14 17:25:13 | <obimod> | doesn't add the gap though, so when screens are changed if it wasn't the original screen it's hidden in the background |
| 2021-11-14 17:25:45 | <obimod> | nice for fixing placement when i change from docked to undocked (screen 0 changes monitors) |
| 2021-11-14 17:27:04 | <geekosaur> | I think that's a downside of the way we currently handle struts. what we do now is much faster than how it used to work (all the real work was in avoidStruts) but means strut changes can be missed |
| 2021-11-14 17:28:38 | <geekosaur> | but I don't run xmobar and don't know it that well, so there are limits to how much I can help with it |
| 2021-11-14 17:28:53 | <obimod> | ahh - i was wondering about those changes -- i do see avoidStruts but then we toggleStruts to add and remove the gap |
| 2021-11-14 17:29:10 | → | SenranKaguya joins (~weechat@c-73-15-19-170.hsd1.ca.comcast.net) |
| 2021-11-14 17:29:12 | <geekosaur> | right, but it's when we *record* the struts that matters |
| 2021-11-14 17:29:14 | <obimod> | i really appreciate the look over though geekosaur |
| 2021-11-14 17:29:24 | → | Guest44 joins (~Guest44@2603-6081-7700-dffb-800e-a94a-caeb-828d.res6.spectrum.com) |
| 2021-11-14 17:29:40 | <geekosaur> | used to be we did it in avoidStruts, which as a result had to examine every window. this got slow with lots of windows |
| 2021-11-14 17:30:05 | <obimod> | that makes sense |
| 2021-11-14 17:30:06 | <geekosaur> | now we track what the docks are and record their struts, but that means we don't notice when their struts change, I think |
| 2021-11-14 17:30:48 | <obimod> | sounds like a sensible trade off |
| 2021-11-14 17:30:52 | <geekosaur> | (should be fixable by monitoring properties on strut-holding windows, come to think of it. you might file an issue about that) |
| 2021-11-14 17:32:27 | <geekosaur> | mm, I thought maybe we already did that in docksEventHook but you have that |
| 2021-11-14 17:34:49 | <geekosaur> | actually this seems a little weird because it's the case the old docksEventHook was specifically intended to handle, docks jumping screens. but I haven't kept track of how it has changed since the 0.12 rewrite |
| 2021-11-14 17:38:20 | <obimod> | i dont think new docks are being setup for xmobar on any other screen than 0 -- i wonder if xmobar is missing some calls with regards to docking |
| 2021-11-14 17:39:08 | <obimod> | for instance, i would expect the SIGUSR1 to jump the dock to the new screen |
| 2021-11-14 17:39:22 | <obimod> | SIGUSR1 to xmobar that is |
| 2021-11-14 17:39:36 | × | Guest44 quits (~Guest44@2603-6081-7700-dffb-800e-a94a-caeb-828d.res6.spectrum.com) (Quit: Client closed) |
| 2021-11-14 17:39:48 | × | noex quits (~noex@2600:8804:1280:aa0:5857:94a:25de:c513) (Quit: my dad's not a phone!) |
| 2021-11-14 17:40:00 | → | Guest44 joins (~Guest44@2603-6081-7700-dffb-800e-a94a-caeb-828d.res6.spectrum.com) |
| 2021-11-14 17:40:22 | <obimod> | (assuming i am getting this terminology right) |
| 2021-11-14 17:42:04 | → | noex joins (~noex@2600:8804:1280:aa0:5857:94a:25de:c513) |
| 2021-11-14 17:43:24 | <obimod> | i think by "gap" i mean "dock" |
| 2021-11-14 17:44:26 | × | Guest44 quits (~Guest44@2603-6081-7700-dffb-800e-a94a-caeb-828d.res6.spectrum.com) (Ping timeout: 256 seconds) |
| 2021-11-14 17:46:10 | <obimod> | i think i found the issue geekosaur https://github.com/jaor/xmobar/issues/541#issuecomment-835288052 |
| 2021-11-14 17:47:39 | <geekosaur> | so SIGUSR1 isn't working either? that suggests xmobar is missing multiscreen support or just doesn't detect the mmultiple screens, rather than the issue you pointed to |
| 2021-11-14 17:48:15 | <obimod> | or maybe not, i'm using Top and not static - SIGUSR1 is working, but it's not creating the "gap" on the screen for some reason |
| 2021-11-14 17:48:16 | <geekosaur> | or, I guess, Static simply doesn't work with multiscreen, which would be that issue I guess |
| 2021-11-14 17:48:36 | <obimod> | my bad, that's not the issue |
| 2021-11-14 17:49:07 | <geekosaur> | right, the gap is something else and that should be on xmonad side. but you have that issue plus the multiple spawns issue? or just one? |
| 2021-11-14 17:49:54 | <obimod> | right, both issues |
| 2021-11-14 17:50:53 | <obimod> | i've also added the xmobar config here: https://dpaste.org/D43b (below xmonad.hs) -- in case you were wondering |
All times are in UTC.