Logs: liberachat/#xmonad
| 2022-03-29 11:36:36 | <Ether[m]> | <fizzie> "I use https://hackage.haskell...." <- Will it work? |
| 2022-03-29 11:42:29 | → | benin joins (~benin@183.82.24.110) |
| 2022-03-29 11:49:02 | × | benin quits (~benin@183.82.24.110) (Ping timeout: 272 seconds) |
| 2022-03-29 11:49:24 | <fizzie> | I don't know (like I said, I only use BSP), but I would expect not. The whole concept is about how to navigate among *visible* windows. If your layout just shows one full-screen window, I don't think any of those strategies on finding which window's "left" (/right/up/down) of the current one would do anything. |
| 2022-03-29 11:49:34 | <fizzie> | For the once-in-a-blue-moon situation when I actually have >1 window in a Full layout, I just use the default mod-j/k bindings that move focus in the stack order. |
| 2022-03-29 11:49:56 | → | benin joins (~benin@183.82.24.110) |
| 2022-03-29 12:03:15 | <Solid[m]> | yeah I don't see the advantages of 2D navigation in a layout that... has no 2-dimensional structure |
| 2022-03-29 12:21:09 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2022-03-29 13:42:24 | <Ether[m]> | Is it possible to stop new window from getting the focus? |
| 2022-03-29 13:43:33 | <Ether[m]> | When I spawn a terminal and then another the new instance gets focus. This is good but makes it important for navigation2d to know which window is in the left. |
| 2022-03-29 13:44:11 | <Ether[m]> | Also documentation should have mentioned that. I had to dig into 100 of configs to figure it out. |
| 2022-03-29 13:44:27 | <geekosaur> | https://hackage.haskell.org/package/xmonad-contrib-0.16/docs/XMonad-Hooks-InsertPosition.html |
| 2022-03-29 13:44:38 | <Ether[m]> | s/important/impossible/ |
| 2022-03-29 13:45:09 | <Ether[m]> | Cool! |
| 2022-03-29 13:45:24 | <Ether[m]> | How do I tell it to not focus on the new window? |
| 2022-03-29 13:48:14 | <Ether[m]> | It shows the default behavior only. |
| 2022-03-29 13:49:04 | <Ether[m]> | Master is default |
| 2022-03-29 13:49:10 | <Ether[m]> | End |
| 2022-03-29 13:49:11 | <geekosaur> | add `<+> insertPosition Above Older`, I think. the two behaviors are separate, so it may be `insertPosition Below Newer` instead |
| 2022-03-29 13:49:12 | <Ether[m]> | Below |
| 2022-03-29 13:50:02 | <Ether[m]> | Will try both |
| 2022-03-29 13:51:38 | <geekosaur> | sorry, I haven't used it so I don't know exactly howit behaves :) |
| 2022-03-29 13:55:06 | <abastro[m]> | Does calling `restart` cause some problem? |
| 2022-03-29 13:57:38 | <geekosaur> | it shouldn't |
| 2022-03-29 13:58:00 | <geekosaur> | it's just synchronous, so it can cause noticeable delays |
| 2022-03-29 13:59:07 | <geekosaur> | well, that part doesn't, but the full sequence is `xmonad --recompile && xmonad --restart` and te compile can take a while, and the restart *must* wait for the compile to finish successfully |
| 2022-03-29 13:59:30 | <geekosaur> | so we do it the shell way rather than locking up the whole wm during the compile part |
| 2022-03-29 14:05:00 | <abastro[m]> | Hm, wait I was not specifying enough |
| 2022-03-29 14:05:21 | <abastro[m]> | What I wanted to say was, my programs won't gain focus after it alerts |
| 2022-03-29 14:05:32 | <abastro[m]> | After calling `restart` function. |
| 2022-03-29 14:07:40 | <Ether[m]> | manage Hook = insert Position Below Newer <+> myManageHook |
| 2022-03-29 14:08:01 | <Ether[m]> | Works! But navigation2d doesn't change behavior! |
| 2022-03-29 14:13:45 | <Ether[m]> | geekosaur how do I implement the directional focus shown in; https://youtu.be/70IxjLEmomg |
| 2022-03-29 14:14:10 | <Ether[m]> | I got the dotfiles to work. How do I port it? |
| 2022-03-29 14:15:39 | <geekosaur> | I don'tknow, I'm not really familiar with navigation2D |
| 2022-03-29 14:34:51 | <Ether[m]> | Any suggestions? |
| 2022-03-29 14:35:27 | <Ether[m]> | https://github.com/altercation/dotfiles-tilingwm |
| 2022-03-29 14:35:33 | <Ether[m]> | He has a github |
| 2022-03-29 15:14:51 | → | twiclo joins (~twiclo@2604:7b80:2000:1069:52fc:cedd:fbeb:10c) |
| 2022-03-29 15:15:11 | <twiclo> | Does anyone know of a fix for dmenu showing up on the last screen if you're launching it on a new desktop that doesn't have anything on it yet? |
| 2022-03-29 15:20:33 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.4.1) |
| 2022-03-29 15:31:27 | × | cfricke quits (~cfricke@user/cfricke) (Ping timeout: 260 seconds) |
| 2022-03-29 15:44:38 | × | gdd quits (~gdd@129.199.146.230) (Ping timeout: 272 seconds) |
| 2022-03-29 15:46:29 | → | gdd joins (~gdd@129.199.146.230) |
| 2022-03-29 15:49:02 | × | benin quits (~benin@183.82.24.110) (Quit: The Lounge - https://thelounge.chat) |
| 2022-03-29 16:00:09 | × | liskin[m] quits (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle) |
| 2022-03-29 16:04:42 | × | twiclo quits (~twiclo@2604:7b80:2000:1069:52fc:cedd:fbeb:10c) (Ping timeout: 260 seconds) |
| 2022-03-29 16:05:13 | → | twiclo joins (~twiclo@2604:7b80:2000:1069:cde9:e3cf:754c:100d) |
| 2022-03-29 16:13:27 | <Ether[m]> | <twiclo> "Does anyone know of a fix for..." <- What do you mean by last screen? |
| 2022-03-29 16:13:38 | <Ether[m]> | Are you on a multi monitor setup? |
| 2022-03-29 16:14:24 | <Ether[m]> | You could use rofi, which can be easily configured to change this behavior. |
| 2022-03-29 16:19:03 | × | gdd quits (~gdd@129.199.146.230) (Ping timeout: 260 seconds) |
| 2022-03-29 16:19:11 | <twiclo> | Yeah this is a multi monitor set up. If I move to a new monitor that has nothing on it then dmenu appears on the last monitor I was on |
| 2022-03-29 16:19:24 | → | liskin[m] joins (~liskinmat@2001:470:69fc:105::768) |
| 2022-03-29 16:20:51 | → | gdd joins (~gdd@129.199.146.230) |
| 2022-03-29 16:23:43 | × | twiclo quits (~twiclo@2604:7b80:2000:1069:cde9:e3cf:754c:100d) (Ping timeout: 260 seconds) |
| 2022-03-29 16:24:41 | → | twiclo joins (~twiclo@2604:7b80:2000:1069:52fc:cedd:fbeb:10c) |
| 2022-03-29 16:31:06 | <geekosaur> | that is normal |
| 2022-03-29 16:31:31 | <geekosaur> | you have to not merely move a mouse to a monitor but focus it; that's what the (default) mod-w/e/r bindings are for |
| 2022-03-29 16:31:41 | <liskin> | Solid[m], mc47[m], geekosaur: https://blog.opencollective.com/google-season-of-docs-2022/ - is this of interest or do we think we have good enough docs already? :-) |
| 2022-03-29 16:32:08 | <geekosaur> | I think we can always use better docs, and I've been sitting on that emailfrom them |
| 2022-03-29 16:32:24 | <liskin> | oh crap applications are closed already :-/ |
| 2022-03-29 16:32:49 | <geekosaur> | you might have noticed I tend to add issues for doc things I notice as I go along, then catch up on them later |
| 2022-03-29 16:32:50 | <liskin> | the blog post was published 4 days before the deadline, and applications had been open since feb 23 |
| 2022-03-29 16:32:57 | <liskin> | never mind then :-/ |
| 2022-03-29 16:33:01 | <twiclo> | geekosaur: Right, so on my left monitor I select my far right (mod+r) which has nothing on it. Then I launch dmenu and it shows on my center monitor |
| 2022-03-29 16:33:05 | <geekosaur> | wow, then they also sent the email late |
| 2022-03-29 16:33:12 | <geekosaur> | odd |
| 2022-03-29 16:33:33 | <geekosaur> | that may be something dmenu is doing, then |
| 2022-03-29 16:33:41 | <twiclo> | This didn't happen on i3 |
| 2022-03-29 16:34:08 | <twiclo> | I would just think that since there's nothing to actually select on the monitor that it's not "selected" according to dmenu |
| 2022-03-29 16:52:02 | <geekosaur> | how is dmenu being run to display windows? dmenu_run shows programs; dmenu by itself takes a list of menu items on its stdin and doesn't know about windows |
| 2022-03-29 16:52:44 | <geekosaur> | (I installed dmenu locally and so far can't reproduce your issue) |
| 2022-03-29 16:53:45 | <geekosaur> | huh. just repro-d it |
| 2022-03-29 16:59:27 | <geekosaur> | what's interesting is I used XMonad.Prompt.Shell to run it and that showed upon the correct monitor |
| 2022-03-29 16:59:57 | <geekosaur> | also dmenu doesn't go through the window manager so we shouldn't have any control over where it shows up |
| 2022-03-29 17:02:32 | <geekosaur> | _NET_CURRENT_DESKTOP is correct |
| 2022-03-29 17:03:11 | <twiclo> | Okay so you're saying if I run it through Shell I should be fine? Odd but it works |
| 2022-03-29 17:03:50 | <geekosaur> | no, that's how I'm reproducing it, not using a keybind. and the Shell prompt shows up in the right place but dmenu doesn't |
| 2022-03-29 17:04:21 | <twiclo> | Weird |
| 2022-03-29 17:07:28 | <geekosaur> | I'm running out of time to look into this, I'm about to be kicked out of my apt. for a few hours (bedbug spraying, again) |
| 2022-03-29 18:06:24 | <twiclo> | Geekosaur I'll submit an issue. Thanks for looking into it |
| 2022-03-29 18:08:40 | <fizzie> | I've noticed that too. And that moving the mouse to the "empty" monitor makes the prompt appear on that. |
| 2022-03-29 18:08:59 | <fizzie> | Never been sufficiently irritated by it to follow up on why, just been thinking "oh, I guess that's how it works". |
| 2022-03-29 18:10:47 | <fizzie> | (My mod-{w,e,r} bindings have an extra quirk that if you try to "switch" to the already focused screen, it moves the mouse pointer to the center of that screen, so "recovery" from dmenu popping up on the wrong monitor can be accomplished without leaving the keyboard: cancel the menu, re-switch to the screen to bring the pointer along, and re-trigger the menu.) |
| 2022-03-29 18:10:47 | <twiclo> | https://github.com/xmonad/xmonad/issues/384 |
| 2022-03-29 18:30:50 | → | carloratm joins (carloratm@tilde.club) |
| 2022-03-29 18:30:58 | <carloratm> | Hi all, novice question here |
| 2022-03-29 18:31:42 | <carloratm> | I would like to achieve this flow, I was wondering if that is doable in xmonad: |
| 2022-03-29 18:33:15 | <carloratm> | 1. if I open any window in any workspace and it is the only one, that goes fullscreen. 2. If I open a second window in the same workspace, another layout activates (tall, for example) |
| 2022-03-29 18:40:30 | <Solid> | doesn't pretty much every layout behave like full when there's only a single window? |
| 2022-03-29 18:46:28 | <carloratm> | fullscreen, covering the bar and with no borders (like F11 sullscreen) |
| 2022-03-29 18:54:23 | <fizzie> | The "no borders" part of that should just be a matter of using XMonad.Layout.NoBorders's `smartBorders` modifier. (Or `lessBorders` with a suitable ambiguity configuration, if you have more than one monitor and still want that to happen; the default is not to, to indicate which one has focus.) |
| 2022-03-29 18:54:42 | <fizzie> | (The part about covering the bar sounds trickier.) |
| 2022-03-29 18:59:26 | <Solid> | I mean, you could make a layout that just asigns a window the whole screen rectangle |
| 2022-03-29 18:59:32 | <Solid> | and not have avoidStruts on that one |
| 2022-03-29 18:59:57 | <Solid> | AFAIR there are some contrib modules that let you decide which layout to use depending on the number of windows |
| 2022-03-29 19:00:25 | <carloratm> | ah that is interesting |
| 2022-03-29 19:00:32 | <fizzie> | I've got a non-`avoidStruts` Full on my list, and yeah, that does ring some sort of a bell. |
| 2022-03-29 19:00:57 | <fizzie> | XMonad.Layout.IfMax? |
All times are in UTC.