Logs: freenode/#xmonad
| 2020-12-27 15:10:52 | <geekosaur> | (I'm catching up on the discussion) |
| 2020-12-27 15:10:54 | <ElKowar> | I guess it would make sense to have the first one be something like "XMonad Popup"? |
| 2020-12-27 15:11:21 | <ElKowar> | hmm lemme read the docs for WM_WINDOW_ROLE quicky |
| 2020-12-27 15:13:41 | <ElKowar> | > The client must set the WM_WINDOW_ROLE property to a string that uniquely identifies that window among all windows that have the same client leader window. |
| 2020-12-27 15:13:43 | <lambdabot> | <hint>:1:156: error: |
| 2020-12-27 15:13:44 | <lambdabot> | <hint>:1:156: error: |
| 2020-12-27 15:13:44 | <lambdabot> | parse error (possibly incorrect indentation or mismatched brackets) |
| 2020-12-27 15:13:51 | <ElKowar> | oh god lol |
| 2020-12-27 15:16:12 | <ElKowar> | The WM_WINDOW_ROLE spec seems to specificall be related to session management and stuff like that, which doesn't really apply to our usecase,.. or am I missing something? I do see how, semantically, this would be the correct way to handle it tho |
| 2020-12-27 15:19:01 | <geekosaur> | most of that documentation is from ICCCM which only talks abut window and session management |
| 2020-12-27 15:22:28 | <ElKowar> | so you'd say WM_CLASS = ["XMonad", "xmonad"] and WM_WINDOW_ROLE = "Decoration" (for example)? |
| 2020-12-27 15:23:01 | <geekosaur> | yeh |
| 2020-12-27 15:23:48 | <ElKowar> | will do! Do i set the WM_WINDOW_ROLE the same way i do for WM_CLASS? (getAtom + changeProperty32)? or is there some other magic involved (not super fluent in the X property API) |
| 2020-12-27 15:24:13 | <geekosaur> | same way, only with 1 string instead of 2 |
| 2020-12-27 15:24:25 | → | malook joins (~Thunderbi@5.111.64.247) |
| 2020-12-27 15:24:39 | × | malook quits (~Thunderbi@5.111.64.247) (Client Quit) |
| 2020-12-27 15:24:57 | <geekosaur> | although shouldn'tit be changeProperty8 since they're both strings? |
| 2020-12-27 15:25:37 | <ElKowar> | uhh, good point, yea. |
| 2020-12-27 15:42:34 | <ElKowar> | In that case i can't just use getAtom,... I've been searching for reference on how to actually get the `[CChar]` i need in the correct format without a lot of hacky-feeling low-level conversion but couldn't find anything.. are we doing that anywhere else already? |
| 2020-12-27 15:45:02 | <ElKowar> | uhhhh I'm probably looking for setTextProperty, right? |
| 2020-12-27 15:50:14 | <geekosaur> | we have getStringProperty |
| 2020-12-27 15:59:08 | <Liskni_si> | shouldn't WM_WINDOW_ROLE be unique? |
| 2020-12-27 15:59:21 | <Liskni_si> | “The combination of SM_CLIENT_ID and WM_WINDOW_ROLE can be used by other clients to uniquely identify a window across sessions.” |
| 2020-12-27 16:03:38 | <ElKowar> | getStringProperty simply relies on some default encoding? seems kind of fragile :o |
| 2020-12-27 16:03:51 | <ElKowar> | according to the spec it should be unique, yea,.... good point actually |
| 2020-12-27 16:04:46 | <geekosaur> | X11 doesn't really do encodings. getStringProperty tries UTF8_STRING first then falls back to STRING (7-bit ASCII) |
| 2020-12-27 16:05:08 | <geekosaur> | those are property type atoms |
| 2020-12-27 16:08:48 | → | ddellacosta joins (dd@gateway/vpn/mullvad/ddellacosta) |
| 2020-12-27 16:10:44 | <ElKowar> | so i |
| 2020-12-27 16:11:02 | <ElKowar> | so i'd reverse that by just getting the char codes and toEnuming them? |
| 2020-12-27 16:14:57 | → | rabliatu joins (~quassel@89.38.227.92) |
| 2020-12-27 16:15:18 | <geekosaur> | ifyou use STRING then you need to substitute something for any character whose ord is > 127; if UTF8_STRING then yu want to encode the string first |
| 2020-12-27 16:17:24 | × | ElKowar quits (~Srain@p3e9d26c7.dip0.t-ipconnect.de) (Quit: ElKowar) |
| 2020-12-27 16:18:03 | → | ElKowar joins (~Srain@p3e9d26c7.dip0.t-ipconnect.de) |
| 2020-12-27 16:25:35 | → | leon joins (~leon@p3e9d26c7.dip0.t-ipconnect.de) |
| 2020-12-27 16:25:51 | × | leon quits (~leon@p3e9d26c7.dip0.t-ipconnect.de) (Client Quit) |
| 2020-12-27 16:26:00 | → | leon joins (~ElKowar@p3e9d26c7.dip0.t-ipconnect.de) |
| 2020-12-27 16:27:03 | × | leon quits (~ElKowar@p3e9d26c7.dip0.t-ipconnect.de) (Client Quit) |
| 2020-12-27 16:32:17 | → | gzj joins (~gzj@unaffiliated/gzj) |
| 2020-12-27 16:32:33 | → | leon joins (~leon@p3e9d26c7.dip0.t-ipconnect.de) |
| 2020-12-27 16:37:08 | × | gzj quits (~gzj@unaffiliated/gzj) (Ping timeout: 260 seconds) |
| 2020-12-27 16:38:09 | → | malook joins (~Thunderbi@5.111.64.247) |
| 2020-12-27 16:38:39 | × | malook quits (~Thunderbi@5.111.64.247) (Client Quit) |
| 2020-12-27 16:47:21 | × | mc47 quits (~yecinem@141.84.69.87) (Ping timeout: 256 seconds) |
| 2020-12-27 16:54:24 | × | ddellacosta quits (dd@gateway/vpn/mullvad/ddellacosta) (Ping timeout: 265 seconds) |
| 2020-12-27 16:57:20 | → | mc47 joins (~yecinem@141.84.69.87) |
| 2020-12-27 17:14:12 | <leon> | So do we use WM_WINDOW_ROLE anyways, even though it should, according to the spec, be unique - which in this case it would not be? |
| 2020-12-27 17:14:21 | <leon> | or do we stick to setting the WM_CLASS |
| 2020-12-27 17:14:32 | <leon> | or do we just not separate different XMonad-created windows for now |
| 2020-12-27 17:17:55 | <leon> | (this is elkowar, trying out new IRC client, couldn't yet be bothered to set the nick correctly lol) |
| 2020-12-27 17:18:11 | × | ElKowar quits (~Srain@p3e9d26c7.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2020-12-27 17:18:16 | leon | is now known as ElKowar |
| 2020-12-27 17:18:18 | <ElKowar> | there we go |
| 2020-12-27 17:33:44 | → | abhixec joins (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) |
| 2020-12-27 17:38:27 | → | ddellacosta joins (dd@gateway/vpn/mullvad/ddellacosta) |
| 2020-12-27 17:56:37 | × | ddellacosta quits (dd@gateway/vpn/mullvad/ddellacosta) (Ping timeout: 246 seconds) |
| 2020-12-27 18:16:20 | × | mc47 quits (~yecinem@141.84.69.87) (Ping timeout: 272 seconds) |
| 2020-12-27 19:03:20 | → | berberman joins (~berberman@unaffiliated/berberman) |
| 2020-12-27 19:03:52 | × | berberman_ quits (~berberman@unaffiliated/berberman) (Ping timeout: 268 seconds) |
| 2020-12-27 19:31:41 | × | notis quits (~notis@85.203.44.37) (Read error: Connection reset by peer) |
| 2020-12-27 19:33:53 | → | notis joins (~notis@85.203.44.37) |
| 2020-12-27 19:48:47 | → | mc47 joins (~yecinem@89.246.239.190) |
| 2020-12-27 20:34:25 | × | notis quits (~notis@85.203.44.37) (Ping timeout: 264 seconds) |
| 2020-12-27 20:57:18 | <mc47> | Is there anyone using more than one status bar on one screen? Or is my setup just "weird"? |
| 2020-12-27 20:58:28 | <geekosaur> | I have two docks running on one screen, although only one is fed by xmonad |
| 2020-12-27 21:00:06 | mc47 | feels less weird |
| 2020-12-27 21:01:05 | <mc47> | I was brwosing through xmonad-contrib, and it seems that there is a fairly involved module for having status bars on different screens, but nothing for more than one status bar on a given screen |
| 2020-12-27 21:02:48 | <al3x27> | mc47: https://github.com/arcolinux/arcolinux-xmonad-xmobar.git |
| 2020-12-27 21:03:06 | <al3x27> | haven't tried it, so ymmv |
| 2020-12-27 21:05:03 | <geekosaur> | nothing really needed for more than one bar on a screen. the other one is about dynamically adding and removing bars when screens are added/removed |
| 2020-12-27 21:05:53 | <mc47> | al3x27 thanks, I have something similar in my configuration |
| 2020-12-27 21:06:34 | <mc47> | geekosaur yes, I came across that and I'm thinking how can I adapt it to fit my use case |
| 2020-12-27 21:07:12 | <mc47> | Maybe if I come up with something modular I'll push a patch |
| 2020-12-27 21:10:43 | × | geekosaur quits (ae68c070@cpe-174-104-192-112.neo.res.rr.com) (Remote host closed the connection) |
| 2020-12-27 21:10:56 | <al3x27> | mc47: found this one as well: https://github.com/nnoell/dotfiles/blob/master/v4.4/xmonad/xmonad.hs |
| 2020-12-27 21:13:56 | <mc47> | Interesting, all seem to manually start the bars and do all the "plumbing" manually |
| 2020-12-27 21:14:19 | <mc47> | and completely ignore DynamicBars |
| 2020-12-27 21:14:50 | <al3x27> | it's how all the examples do it |
| 2020-12-27 21:15:57 | <al3x27> | XMonad.Hooks.DynamicBars |
| 2020-12-27 21:16:09 | <mc47> | you're right, although that module needs more love :-) I'm still trying to work out how it works exactly, but it seems really interesting |
| 2020-12-27 21:16:14 | <al3x27> | doesn't look very beginner friendly |
| 2020-12-27 21:17:45 | <mc47> | agreed! |
| 2020-12-27 21:20:48 | <al3x27> | the source has almost no comments, compare that to https://hackage.haskell.org/package/xmonad-contrib-0.16/docs/src/XMonad.Hooks.DynamicLog.html which is perfect evening reading |
| 2020-12-27 21:21:00 | al3x27 | likes commented code |
| 2020-12-27 21:23:48 | <mc47> | Yeah I really like the comments in XMonad.Hooks.DynamicLog! |
| 2020-12-27 21:26:29 | <al3x27> | i don't know any haskell, but with that i was able to write a function that replaces my workspace names with icons |
| 2020-12-27 21:27:59 | mc47 | loves to hear about people using haskell without knowing haskell |
| 2020-12-27 21:29:05 | <mc47> | This speaks for how good is the documentation! |
| 2020-12-27 21:29:41 | <mc47> | For me it was the other way around: I learnt Haskell, really liked it, and then later I found out about xmonad and was like "THIS IS IT" |
| 2020-12-27 21:30:19 | <al3x27> | so far haskell it utterly weird, it's all upside-down |
| 2020-12-27 21:31:05 | <al3x27> | but the type system is great, and the error messages are actually helpful |
| 2020-12-27 21:31:26 | <mc47> | maybe everything is upside-down, and Haskell is the correct way to go? |
| 2020-12-27 21:32:58 | <al3x27> | i'll do more reading and let you know ;-) |
| 2020-12-27 21:33:18 | <mc47> | The typesystem is really awesome. if it compiles, it probably works (at least if you're not doing any weird stuff) |
| 2020-12-27 21:33:42 | <mc47> | I have to work with python on another project... The lack of a type system really makes me pull my hair some times |
| 2020-12-27 21:36:24 | <al3x27> | yes, no side effects and strict typing helps a lot, but python has normal loops and you can put print statements everywhere, makes it very noob friendly |
| 2020-12-27 21:36:28 | → | notis joins (~notis@85.203.44.37) |
| 2020-12-27 21:38:20 | <mc47> | Which is a reason why we're using python in that other project, it's accessible for more people |
| 2020-12-27 21:39:27 | → | ADG1089__ joins (~aditya@223.235.213.117) |
| 2020-12-27 21:40:36 | × | notis quits (~notis@85.203.44.37) (Ping timeout: 240 seconds) |
All times are in UTC.