Logs: freenode/#xmonad
| 2021-03-21 09:25:05 | <Solid> | oh that souns lovely |
| 2021-03-21 09:25:09 | <Solid> | *sounds |
| 2021-03-21 09:27:07 | → | elGamal joins (~elg@217.138.212.20) |
| 2021-03-21 09:31:11 | <Solid> | mc47: now I need to resist the temptation to implement repeatLast myself :P |
| 2021-03-21 09:31:46 | <mc47> | I implemented it in my mind before I went to sleep yesterday lol |
| 2021-03-21 09:32:03 | <mc47> | the good thing in xmonad, is that you can implement it in your config and not stage it :D :D :D |
| 2021-03-21 09:32:09 | <mc47> | which is what'll do |
| 2021-03-21 09:32:11 | <Solid> | =) |
| 2021-03-21 09:32:51 | <Solid> | I implemented it (badly) as a literate reddit comment so I hope I didn't give away too much for a potential first contributor ^^' |
| 2021-03-21 09:33:36 | <Solid> | well, I think your proposal has sightly more granular functionality instead of just marking everything as repeatable |
| 2021-03-21 09:33:39 | <Solid> | so it'll probably be fine |
| 2021-03-21 09:40:17 | <mc47> | It's not about the implementation, really, it's just about taking a step to contribute |
| 2021-03-21 09:43:32 | <Solid> | let's hope it works out |
| 2021-03-21 09:43:46 | <Solid> | I've had not-so-great success with trying to get people on reddit to contribute :/ |
| 2021-03-21 09:45:27 | → | seschwar joins (~seschwar@unaffiliated/seschwar) |
| 2021-03-21 09:46:27 | <Liskni_si> | isn't that like saying "I've had not-so-great success hiring senior engineers by having L1 support mention we're hiring at the end of each call" ? :-) |
| 2021-03-21 09:53:36 | <Solid> | it was less "how would YOU like to migrate ewmh support into the core?" and more "hey the docs are a little unclear here, we'd love a little one-line pr" |
| 2021-03-21 09:56:28 | <mc47> | Well, it's a part of open-source |
| 2021-03-21 09:56:52 | <mc47> | you'd need to ask tons of people just to potentially get one active contributor |
| 2021-03-21 09:58:09 | <mc47> | One speaker at the course talked about how he asks everyone he talks to whether they want to contribute, with very little success |
| 2021-03-21 09:59:20 | <mc47> | He asked us if we wanted to contribute, it was... awkward |
| 2021-03-21 09:59:51 | <mc47> | and then joked "See? Like I told you!" |
| 2021-03-21 10:01:35 | <mc47> | Anyway, I'll try to add more challenging issues that are not one-liners, then maybe we can try and get more attention |
| 2021-03-21 10:02:02 | → | dementorr joins (5678f228@86.120.242.40) |
| 2021-03-21 10:03:59 | <Liskni_si> | that reminds me that the Haskell weekly "call for participation" is usually a short list of individual issues, not link to a project's first issues |
| 2021-03-21 10:04:07 | <Liskni_si> | like this: https://haskellweekly.news/issue/254.html |
| 2021-03-21 10:04:38 | <Liskni_si> | it probably doesn't matter much, just we'll need to chose one that sounds catchy and hope people will click through |
| 2021-03-21 10:05:48 | <mc47> | We could always make a call for participation and post it here and there |
| 2021-03-21 10:06:07 | <Liskni_si> | yeah that's true |
| 2021-03-21 10:09:13 | <mc47> | maybe I convince the organizers of the haskell course at the uni to post it there, since they also organized the practical course :) |
| 2021-03-21 10:09:37 | <mc47> | s/there/to the students |
| 2021-03-21 10:18:34 | <dementorr> | Hello! I am trying to make xmobar show only the workspaces from the current screen. With the normal ppVisible I get ` (0_1) [1_1] 0_2 0_3 1_2 1_3 ` on all screens. What I would like is to get (0_1) 0_2 0_3 on screen 0 and [1_1] 1_2 1_3 on screen 1. If I put ppVisible = const "" I would still get hidden workspaces from other screens. In this paste: |
| 2021-03-21 10:18:34 | <dementorr> | https://pastebin.com/d5xPfh0e I managed to display only workspaces from screen 0 (but still on all screens). Can I modify the '0' to match the current screenId (and hide them from other screens)? Somehow ppCurrent knows the current screen id... |
| 2021-03-21 10:21:41 | × | elGamal quits (~elg@217.138.212.20) (Quit: ZNC 1.7.5 - https://znc.in) |
| 2021-03-21 10:40:11 | → | idhugo__ joins (~idhugo@87-49-146-176-mobile.dk.customer.tdc.net) |
| 2021-03-21 10:43:01 | × | idhugo_ quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 256 seconds) |
| 2021-03-21 12:15:36 | → | thoros joins (~thoros@194-166-47-167.hdsl.highway.telekom.at) |
| 2021-03-21 12:44:49 | → | remo joins (~user@wheelly-shelter.volia.net) |
| 2021-03-21 12:45:19 | <remo> | How to fix open keepassx/keepassxc? |
| 2021-03-21 12:46:19 | × | remo quits (~user@wheelly-shelter.volia.net) (Client Quit) |
| 2021-03-21 12:52:54 | <mc47> | What are you trying to do exactly, dementorr ? |
| 2021-03-21 12:54:58 | <mc47> | if you're trying to have independent workspaces in the screens, you might want to take a look at XMonad.Layout.IndependentScreens |
| 2021-03-21 13:03:30 | <Liskni_si> | I smell some dynamic per-screen xmobars in there, with marshallPP or something |
| 2021-03-21 13:07:14 | → | idhugo_ joins (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) |
| 2021-03-21 13:10:03 | × | idhugo__ quits (~idhugo@87-49-146-176-mobile.dk.customer.tdc.net) (Ping timeout: 260 seconds) |
| 2021-03-21 13:22:21 | <dementorr> | mc47, Liskni_si: Yes you're both right. So I am using Independent Screens (so each screen has a set of 10 workspaces) and XMonad.Hooks.DynamicBars that handles the spawn of xmobar for each screen. The problem is that DynamicBars holds the state inside the module so I can't get the handles to xmobar (I can only customize them with PP). The problem |
| 2021-03-21 13:22:21 | <dementorr> | is that the same state is path to all xmobars so I can't customize each one (except in basic ways with ppSort/ppOrder/ppHidden etc) |
| 2021-03-21 13:24:43 | <dementorr> | *path --> passed |
| 2021-03-21 14:11:53 | → | kelnoky joins (~shao@ip1f128ba7.dynamic.kabel-deutschland.de) |
| 2021-03-21 14:13:12 | → | geekosaur joins (ae68c070@cpe-174-104-192-112.neo.res.rr.com) |
| 2021-03-21 14:20:04 | → | qbit2821 joins (~qbit2821@94-255-133-216.cust.bredband2.com) |
| 2021-03-21 14:24:13 | → | wonko7 joins (~wonko7@45.15.17.60) |
| 2021-03-21 14:46:43 | × | incertia quits (~incertia@d4-50-26-103.nap.wideopenwest.com) (Ping timeout: 245 seconds) |
| 2021-03-21 14:47:41 | → | incertia joins (~incertia@d4-50-26-103.nap.wideopenwest.com) |
| 2021-03-21 14:50:02 | → | Zetagon joins (~leo@c151-177-52-233.bredband.comhem.se) |
| 2021-03-21 14:57:33 | × | incertia quits (~incertia@d4-50-26-103.nap.wideopenwest.com) (Ping timeout: 264 seconds) |
| 2021-03-21 15:02:26 | → | incertia joins (~incertia@d4-50-26-103.nap.wideopenwest.com) |
| 2021-03-21 15:10:54 | <Liskni_si> | dementorr: mc47 has an open pullreq with a better version of DynamicBars; might want to give that a try |
| 2021-03-21 15:50:09 | × | incertia quits (~incertia@d4-50-26-103.nap.wideopenwest.com) (Ping timeout: 256 seconds) |
| 2021-03-21 16:13:06 | × | idhugo_ quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 246 seconds) |
| 2021-03-21 16:34:24 | → | remo joins (~remo@wheelly-shelter.volia.net) |
| 2021-03-21 16:34:48 | × | remo quits (~remo@wheelly-shelter.volia.net) (Remote host closed the connection) |
| 2021-03-21 16:36:06 | → | remo joins (~remo@wheelly-shelter.volia.net) |
| 2021-03-21 16:39:08 | × | dementorr quits (5678f228@86.120.242.40) (Quit: Connection closed) |
| 2021-03-21 16:47:33 | × | Zetagon quits (~leo@c151-177-52-233.bredband.comhem.se) (Remote host closed the connection) |
| 2021-03-21 16:50:06 | → | incertia joins (~incertia@d4-50-26-103.nap.wideopenwest.com) |
| 2021-03-21 16:51:23 | <mc47> | Like Liskni_si said, if you could wait a bit (or build xmonad-contrib from source) then you can use a nicer abstraction to work with |
| 2021-03-21 17:02:01 | <geekosaur> | dementorr left |
| 2021-03-21 17:02:15 | <mc47> | they always do... |
| 2021-03-21 17:02:54 | <Solid> | geekosaur: re #185: the problem is that I don't quite know what your a assessment _is_ :) |
| 2021-03-21 17:04:30 | <geekosaur> | https://github.com/xmonad/xmonad-contrib/pull/185#issuecomment-303271733 ? |
| 2021-03-21 17:04:48 | <geekosaur> | nothing has changed since then |
| 2021-03-21 17:06:00 | <Solid> | to me, that mostly seems like "xdotool is doing something shady for circumvention" and I can't quite tell whether you're saying that this would be worth doing or not |
| 2021-03-21 17:06:27 | × | coldpress quits (~coldpress@128.9.105.34.bc.googleusercontent.com) (Ping timeout: 265 seconds) |
| 2021-03-21 17:08:10 | <geekosaur> | I'm not sure what xdotool is doing for circumvention, since it also has a mode where it'll use the XTEST extension which is dubious at best |
| 2021-03-21 17:08:36 | <geekosaur> | although come to think of it, that can't help here since it still wouldn't pass the keysym, only a keycode |
| 2021-03-21 17:09:19 | <geekosaur> | but it is known to leave a background process in some cases to clean up after itself so that's probably what it's doing. and I don't think we should do that (or even a background thread) |
| 2021-03-21 17:12:00 | → | idhugo_ joins (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) |
| 2021-03-21 17:30:30 | → | ADG1089__ joins (~aditya@27.58.165.185) |
| 2021-03-21 17:30:57 | ADG1089__ | is now known as ADG1089 |
| 2021-03-21 17:34:09 | × | srk quits (~sorki@gateway/tor-sasl/sorki) (Remote host closed the connection) |
| 2021-03-21 17:34:09 | × | hexo quits (~hexo@gateway/tor-sasl/hexo) (Remote host closed the connection) |
| 2021-03-21 17:34:23 | → | srk joins (~sorki@gateway/tor-sasl/sorki) |
| 2021-03-21 17:34:28 | → | hexo joins (~hexo@gateway/tor-sasl/hexo) |
| 2021-03-21 17:35:44 | × | kiki_kiki quits (~kiki@78.97.179.238) (Ping timeout: 240 seconds) |
| 2021-03-21 17:40:13 | → | kiki_kiki joins (~kiki@78.97.179.238) |
| 2021-03-21 17:44:38 | × | kiki_kiki quits (~kiki@78.97.179.238) (Ping timeout: 245 seconds) |
| 2021-03-21 17:55:28 | → | xaltsc joins (~xaltsc@unaffiliated/xaltsc) |
| 2021-03-21 18:00:34 | → | coldpress joins (~coldpress@128.9.105.34.bc.googleusercontent.com) |
| 2021-03-21 18:12:06 | × | qbit2821 quits (~qbit2821@94-255-133-216.cust.bredband2.com) (Ping timeout: 246 seconds) |
| 2021-03-21 18:12:52 | × | mc47 quits (~yecinem@89.246.239.190) (Remote host closed the connection) |
| 2021-03-21 18:19:50 | → | growpotkin joins (~growpotki@130-45-30-154.dyn.grandenetworks.net) |
| 2021-03-21 18:20:10 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2021-03-21 18:43:02 | × | coldpress quits (~coldpress@128.9.105.34.bc.googleusercontent.com) (Ping timeout: 256 seconds) |
| 2021-03-21 19:08:26 | × | remo quits (~remo@wheelly-shelter.volia.net) (Remote host closed the connection) |
| 2021-03-21 19:10:09 | × | xaltsc quits (~xaltsc@unaffiliated/xaltsc) (Ping timeout: 264 seconds) |
| 2021-03-21 19:58:23 | × | idhugo_ quits (~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Ping timeout: 260 seconds) |
| 2021-03-21 20:21:43 | × | ADG1089 quits (~aditya@27.58.165.185) (Read error: Connection reset by peer) |
| 2021-03-21 20:28:23 | × | geekosaur quits (ae68c070@cpe-174-104-192-112.neo.res.rr.com) (Quit: Connection closed) |
| 2021-03-21 20:55:12 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
All times are in UTC.