Logs: liberachat/#xmonad
| 2022-08-04 18:46:57 | <geekosaur> | not wure WN is all that useful with Full though |
| 2022-08-04 18:46:57 | <Guest8383> | but what difference does it make? |
| 2022-08-04 18:47:44 | <geekosaur> | and boringWindows just makes WN behave a bit better so they should go together |
| 2022-08-04 18:47:54 | <geekosaur> | *sure |
| 2022-08-04 18:48:34 | <Guest8383> | okay |
| 2022-08-04 19:00:53 | <Guest8383> | also |
| 2022-08-04 19:00:57 | <Guest8383> | why doesn't this: |
| 2022-08-04 19:01:00 | <Guest8383> | ("M-u", setLayout Full), |
| 2022-08-04 19:01:02 | <Guest8383> | work? |
| 2022-08-04 19:01:13 | <Guest8383> | i don't understand the types expected by setLayout? |
| 2022-08-04 19:01:33 | <geekosaur> | oh, hm. I bet it needs a layout wrapped in an existential |
| 2022-08-04 19:01:40 | <geekosaur> | that's going to bve harder |
| 2022-08-04 19:02:08 | <geekosaur> | but since you've solved the problem with Full in the layout, you can go back to using JumpToLayout |
| 2022-08-04 19:03:31 | <geekosaur> | we do something slightly evil with layouts, since otherwise we can't sanely work with them because their types depend on exactly what you've done |
| 2022-08-04 19:06:48 | <diep> | In my manageHook, there is a way to add to a match, like `className =? "feh"`, both `doFloat` and `hasBorder False` instructions? |
| 2022-08-04 19:07:43 | <diep> | Or I have to write two separate match, one to apply doFloat, the other one hasBorder? |
| 2022-08-04 19:08:44 | <geekosaur[m]> | Use `<>` to combine them |
| 2022-08-04 19:09:01 | <diep> | I try |
| 2022-08-04 19:10:10 | <diep> | thx again, works perfectly |
| 2022-08-04 19:12:22 | <Guest8383> | geekosaur ughh |
| 2022-08-04 19:12:33 | <Guest8383> | this time I wanted to use another layout to jump to |
| 2022-08-04 19:13:06 | <Guest8383> | isn't there a way to jump to a layout and not have to cycle through it |
| 2022-08-04 19:13:19 | <geekosaur[m]> | Nope |
| 2022-08-04 19:13:30 | <Guest8383> | okay |
| 2022-08-04 19:13:56 | <Guest8383> | I would say that one thing is necessary |
| 2022-08-04 19:14:04 | <Guest8383> | really needed that |
| 2022-08-04 19:14:48 | <geekosaur[m]> | A layout is secretly a function; it has to be run to get to a particular point in it |
| 2022-08-04 19:17:43 | <geekosaur[m]> | This is also why you can't go backwards |
| 2022-08-04 19:20:49 | <[Leary]> | You can write a layout modifier which takes some `X Bool` predicate (say, reading a toggle from extensible state) and switches into an alternative layout when it holds. |
| 2022-08-04 19:21:00 | <[Leary]> | Not sure if we have something like that already. |
| 2022-08-04 19:21:53 | <[Leary]> | Oh, actually I guess you need Read? |
| 2022-08-04 19:22:03 | <[Leary]> | That's a pain. |
| 2022-08-04 19:22:14 | <geekosaur> | see how (|||) works |
| 2022-08-04 19:23:47 | <geekosaur> | you can do something like that but you need to hide the predicate inside the implementation |
| 2022-08-04 19:24:16 | <geekosaur> | so you could for example take a String and compare it against something in XS |
| 2022-08-04 19:24:45 | <[Leary]> | Right, or have it sent with the message, and store the result for runLayout. |
| 2022-08-04 19:24:48 | <geekosaur> | you can also send it a predicate via a message, which doesn't require Read since it's not serialized |
| 2022-08-04 19:27:07 | <[Leary]> | I suspect this would generalise several layout modifiers... |
| 2022-08-04 19:27:39 | <geekosaur> | likely |
| 2022-08-04 19:28:24 | <geekosaur> | I think we already have a note in an issue to consider merging some layout modifiers that way, but we decided it would be too confusing for users unless we still provided the originals as wrappers for it |
| 2022-08-04 19:55:19 | × | diep quits (~diep@2a01:cb11:2d7:4a00:a13f:e40c:c4e8:736c) (Remote host closed the connection) |
| 2022-08-04 20:17:51 | <Guest8383> | hey geekosaur |
| 2022-08-04 20:17:56 | <Guest8383> | one more thing btw |
| 2022-08-04 20:18:02 | <geekosaur> | yes? |
| 2022-08-04 20:18:10 | <Guest8383> | when using a subtabbed layout |
| 2022-08-04 20:18:28 | <Guest8383> | suppose i have a tabbed group with three tabs on my left half of the screen |
| 2022-08-04 20:18:33 | <Guest8383> | and my focus is on that group |
| 2022-08-04 20:18:41 | <Guest8383> | then |
| 2022-08-04 20:18:49 | <Guest8383> | using the binding to toggle the scratchpads |
| 2022-08-04 20:19:01 | <Guest8383> | also affects the tabgroup |
| 2022-08-04 20:19:13 | <Guest8383> | in the background it switches to the first tab |
| 2022-08-04 20:19:18 | <Guest8383> | why is that? |
| 2022-08-04 20:19:54 | <geekosaur> | because there's really only one list of windows for the workspace and it gets ordered somewhat oddly especially when sublayouts are in use |
| 2022-08-04 20:20:02 | <geekosaur> | TrackFloating may help some |
| 2022-08-04 20:20:23 | <geekosaur> | https://hackage.haskell.org/package/xmonad-contrib-0.17.0/docs/XMonad-Layout-TrackFloating.html |
| 2022-08-04 20:20:55 | <geekosaur> | but ultimately it's a fundamental bug in how we track windows that is really hard to fix without breaking compatibility |
| 2022-08-04 20:21:29 | <geekosaur> | the StackSet is unforgiving and doesn't quite behave the same way people think |
| 2022-08-04 20:22:00 | × | sogens quits (~sogens@211.30.173.20) (Quit: WeeChat 3.5) |
| 2022-08-04 20:23:29 | <Guest8383> | umm |
| 2022-08-04 20:23:45 | <Guest8383> | applying trackfloating to my layout doesn't fix the problem |
| 2022-08-04 20:23:58 | <geekosaur> | I did say "may help" |
| 2022-08-04 20:24:10 | <Guest8383> | oh so is that something I'll have to live with? |
| 2022-08-04 20:24:20 | → | sogens joins (~sogens@211.30.173.20) |
| 2022-08-04 20:25:02 | <geekosaur> | really, things like floating windows (in particular ones managed in a different way, like scratchpads) really ought to have their own stacks instead of being intermingled into the same underlying workspace stack |
| 2022-08-04 20:25:31 | <Guest8383> | but that's not the case here right? |
| 2022-08-04 20:25:36 | <geekosaur> | wherever the window gets inserted will affect display of every other window in the stack, leading to the behavior you're seeing. and yes, you'll just have to live with it |
| 2022-08-04 20:25:51 | <Guest8383> | ugh |
| 2022-08-04 20:26:19 | <geekosaur> | someday I'll get all the old bugs transferred over to github maybe; this was bug 4 in the original bug tracker, to tell you how long it's been around |
| 2022-08-04 20:26:35 | <Guest8383> | damn |
| 2022-08-04 20:27:04 | <geekosaur> | it is *by far* our biggest shortcoming 😞 |
| 2022-08-04 20:27:12 | <Guest8383> | why is xmonad's development so slow? |
| 2022-08-04 20:27:37 | <geekosaur> | because nobody wants to break the core, including breaking backward compatibility |
| 2022-08-04 20:27:59 | <geekosaur> | redoing the StackSet and its relationship to workspaces would break pretty much everything, sadly |
| 2022-08-04 20:28:39 | <Guest8383> | so why not do it in an entirely new release |
| 2022-08-04 20:29:01 | <geekosaur> | we'd have to remove pretty much all of contrib as part of that release |
| 2022-08-04 20:29:26 | <Guest8383> | If that's done then that'll be one of the best days of my life |
| 2022-08-04 20:29:29 | <Guest8383> | not kidding |
| 2022-08-04 20:29:37 | <geekosaur> | it'd all have to be redone from scratch, and who knows where the original contributors are? and some of the things in there we don't really understand enough to rewrite |
| 2022-08-04 20:29:58 | <geekosaur> | like nobody wants to touch MultiToggle |
| 2022-08-04 20:30:12 | <Guest8383> | I always dream of xmonad's clone in rust |
| 2022-08-04 20:30:58 | <geekosaur> | wouldn't surprise me if it happens, although it's a bit more likely to actually be a dwm clone (xmonad is more or less dwm done in haskell) |
| 2022-08-04 20:31:36 | <Guest8383> | so dwm is older than xmonad? |
| 2022-08-04 20:31:44 | <Guest8383> | I actually came from dwm |
| 2022-08-04 20:32:02 | <Guest8383> | I was tired of patching things and then fixing and fiddling with patches |
| 2022-08-04 20:32:10 | <Guest8383> | not the way I'd want to configure things |
| 2022-08-04 20:32:16 | <[Leary]> | Guest8383: I wrote X.L.StateFull.focusTracking to fix this issue, but iirc it somewhat duplicated the module geekosaur recommended; I'm not sure how different they are. That said, I don't see why it shouldn't work if you apply it to the sublayout. |
| 2022-08-04 20:32:27 | <Guest8383> | and xmonad has more features i think |
| 2022-08-04 20:33:57 | × | sogens quits (~sogens@211.30.173.20) (Quit: WeeChat 3.5) |
| 2022-08-04 20:34:06 | <geekosaur> | sjanssen came from dwm and felt that a haskell dsl would be an improvement over patching the window manager core to add features, so xmonad was born |
| 2022-08-04 20:34:42 | <geekosaur> | the core is still almost identical to what he wrote back in 2006 |
| 2022-08-04 20:35:18 | <geekosaur> | we've moved some things into the config record that had been hardcoded and added basic support for extensiblestate, but I think that's pretty much it for changes to the core |
| 2022-08-04 20:35:31 | <Guest8383> | Isn't janssen the same guy who wrote kmonad? |
| 2022-08-04 20:35:56 | <Guest8383> | [Leary] I'm not sure if i did it correctly but doesn't seem to worl |
| 2022-08-04 20:35:59 | <Guest8383> | work* |
| 2022-08-04 20:36:05 | <geekosaur> | spencer janssen, not david |
| 2022-08-04 20:36:14 | → | sogens joins (~sogens@211.30.173.20) |
| 2022-08-04 20:36:22 | <Guest8383> | oh |
| 2022-08-04 20:36:25 | <Guest8383> | hehe |
| 2022-08-04 20:36:29 | <Guest8383> | [Leary] |
| 2022-08-04 20:36:30 | <Guest8383> | import XMonad.Layout.StateFull (focusTracking) |
All times are in UTC.