| 2024-06-18 00:10:50 +0200 | <haskellbridge> | <iqubic (she/her)> https://dpaste.com/7DK35KQXB |
| 2024-06-18 00:11:58 +0200 | <haskellbridge> | <iqubic (she/her)> I have no idea how this works... If I'm in "Mirror tall" and I toggle to fullscreen and back, XMonad remembers that I was in Mirror tall. How does it remember that?!?! |
| 2024-06-18 00:18:39 +0200 | <geekosaur> | the ToggleLayouts data constructor holds state. Running a layout or sending a message can replace the constructor with a new value |
| 2024-06-18 00:18:59 +0200 | <geekosaur> | In this case, the value is a Bool indicating whether the layout is toggled or not |
| 2024-06-18 00:21:34 +0200 | <haskellbridge> | <iqubic (she/her)> Does I assume the (|||) layout combinator just tracks the state of which layout I'm using. |
| 2024-06-18 00:21:50 +0200 | <geekosaur> | yes |
| 2024-06-18 00:22:02 +0200 | <geekosaur> | its constructor is Choose, which contains a Bool |
| 2024-06-18 00:22:20 +0200 | <geekosaur> | hm, actually I think it uses a bespoke type which is either Left or Right |
| 2024-06-18 00:22:43 +0200 | <geekosaur> | when the layout is initialized, all Choose constructors have Left |
| 2024-06-18 00:23:30 +0200 | <geekosaur> | every time you mod-space, every Choose constructor checks its state: if it's Left then it changes the state to Right; if it's Right then it relays the message to its rightward layout |
| 2024-06-18 00:23:57 +0200 | <geekosaur> | when a layout is run, Choose runs either its Left or Right layout depending on the state |
| 2024-06-18 00:25:53 +0200 | <geekosaur> | (iirc "Left" and "Right" are actually called "CL" and "CR") |
| 2024-06-18 00:26:27 +0200 | <haskellbridge> | <iqubic (she/her)> CL and CR are the constructors, yeah. |
| 2024-06-18 00:28:39 +0200 | <haskellbridge> | <iqubic (she/her)> So, the "Toggle" layout remembers the state of the two layouts it lets me toggle between. |
| 2024-06-18 00:29:06 +0200 | <geekosaur> | right |
| 2024-06-18 00:29:23 +0200 | <geekosaur> | it's ToggleLayout Bool leftlayout rightlayout |
| 2024-06-18 00:29:46 +0200 | <geekosaur> | if the Bool is True then it's toggled on and runs leftlayout, otherwise rightlayout |
| 2024-06-18 00:30:26 +0200 | <geekosaur> | er, ToggleLayouts. "ToggleLayout" is the message constructor which toggles the Bool |
| 2024-06-18 00:30:43 +0200 | <haskellbridge> | <iqubic (she/her)> Is there a way I can debug why a namedScratchpadAction isn't working for me? |
| 2024-06-18 00:31:38 +0200 | <haskellbridge> | <iqubic (she/her)> Like, I have a list of scratchpads defined and I have a keybinding set for it. But invoking the keybinding doesn't seem to do anything. |
| 2024-06-18 00:37:24 +0200 | <geekosaur> | did you remember to add namedScratchpadManageHook to the manageHook? that's a fairly common mistake (and I've made it myself 🙂 ) |
| 2024-06-18 00:37:40 +0200 | <haskellbridge> | <iqubic (she/her)> Uh... I don't think I did that. |
| 2024-06-18 00:37:45 +0200 | <haskellbridge> | <iqubic (she/her)> What should that look like? |
| 2024-06-18 00:37:48 +0200 | <geekosaur> | pass it the list of NamedScratchPads |
| 2024-06-18 00:38:02 +0200 | <geekosaur> | , manageHook = namedScratchpadManageHook scratchpads |
| 2024-06-18 00:38:20 +0200 | <geekosaur> | as usual use <> <+> or composeAll to combine it with other manageHooks |
| 2024-06-18 00:45:36 +0200 | <haskellbridge> | <iqubic (she/her)> Yeah. I know how to add a ManageHook to my already existing manage hooks. |
| 2024-06-18 00:52:24 +0200 | <haskellbridge> | <iqubic (she/her)> I just added it to my manageHook and it's still not working. |
| 2024-06-18 00:59:37 +0200 | <geekosaur> | https://github.com/geekosaur/xmonad.hs/blob/hilfy-2023/xmonad.hs#L166-L179 (manageHook) https://github.com/geekosaur/xmonad.hs/blob/hilfy-2023/xmonad.hs#L223-L235 (keys) |
| 2024-06-18 01:01:47 +0200 | <haskellbridge> | <iqubic (she/her)> I found the error. In the first argument for NS, I used uppercased the first letter of the name. In the keybindings I used all lowercase names. |
| 2024-06-18 01:12:09 +0200 | <haskellbridge> | <iqubic (she/her)> This looks really wonderful. I'm loving this: https://imgur.com/a/LiffReW |
| 2024-06-18 01:35:29 +0200 | <haskellbridge> | <iqubic (she/her)> Is there a way that I can write a simple function to create a centered RationalRect? Like "centered :: Rational -> Rational -> RationalRect" where I give it a width and a height in fractions of the screen size, and it works out where the top left corner should be for me, so that the rectangle is centered. |
| 2024-06-18 01:35:38 +0200 | <haskellbridge> | <iqubic (she/her)> Or is that something that already exists? |
| 2024-06-18 01:36:55 +0200 | <haskellbridge> | <iqubic (she/her)> I want something like "doCenteredFloat" but with the ability to specify a height and a width. |
| 2024-06-18 01:42:27 +0200 | <geekosaur> | doesn't look like we have anything conveniently prepackaged, but you can derive it from the local function `move` that's part of https://hackage.haskell.org/package/xmonad-contrib-0.18.0/docs/src/XMonad.Hooks.ManageHelpers.html… |
| 2024-06-18 01:43:03 +0200 | <haskellbridge> | <iqubic (she/her)> Cool. Thanks! |
| 2024-06-18 01:50:26 +0200 | <geekosaur> | hm, you might also need https://hackage.haskell.org/package/xmonad-0.18.0/docs/XMonad-Operations.html#v:floatLocation |
| 2024-06-18 01:53:04 +0200 | <haskellbridge> | <iqubic (she/her)> Hmm... yeah, maybe. |
| 2024-06-18 02:00:56 +0200 | <geekosaur> | unfortunately that's the only place where we generate a RationalRect from a Rectangle; everything else goes the other direction (scaling a Rectangle according to a RationalRect) |
| 2024-06-18 02:02:09 +0200 | <haskellbridge> | <iqubic (she/her)> Well, I'm just gonna be passing this RationalRect into "customFloat" to place my Named Scratch Pad. |
| 2024-06-18 03:48:00 +0200 | <haskellbridge> | <iqubic (she/her)> Does something like this work for doing scratchpad manage hooks? https://dpaste.com/3E3T9BR7J |
| 2024-06-18 03:49:16 +0200 | <haskellbridge> | <iqubic (she/her)> I just have to fiddle with the values to get something I like, but I think that should work. |
| 2024-06-18 03:51:47 +0200 | <geekosaur> | it should |
| 2024-06-18 03:52:23 +0200 | <geekosaur> | I think I have something in my scratchpads where I messed with numbers until I got it to work (actually I think I computed it by hand and then adjusted until it works) |
| 2024-06-18 03:53:08 +0200 | <haskellbridge> | <iqubic (she/her)> I am just messing with these numbers until I get something that looks good to me. |
| 2024-06-18 03:53:29 +0200 | <haskellbridge> | <iqubic (she/her)> But that should make the windows centered right? |
| 2024-06-18 03:56:05 +0200 | <geekosaur> | it should, yes |
| 2024-06-18 03:57:06 +0200 | <haskellbridge> | <iqubic (she/her)> Just checking that I got my math right. |
| 2024-06-18 03:59:11 +0200 | <haskellbridge> | <iqubic (she/her)> Is 222 lines of xmonad config too much? |
| 2024-06-18 04:00:15 +0200 | <geekosaur> | I have just over 450 😛 |
| 2024-06-18 04:01:24 +0200 | <haskellbridge> | <iqubic (she/her)> Will longer config mean slower WM? |
| 2024-06-18 04:01:34 +0200 | <geekosaur> | not necessarily |
| 2024-06-18 04:02:06 +0200 | <geekosaur> | if you have a lot of handleEventHooks or a large logHook, you may have issues |
| 2024-06-18 04:02:37 +0200 | <geekosaur> | a large keymap, for example, won't slow things down because it's compiled to (possibly nested) maps |
| 2024-06-18 04:03:07 +0200 | <haskellbridge> | <iqubic (she/her)> Also, I've noticed that named scratchpads only change their size after I restart xmonad and also kill the window. It's like the manage hook is only run at window creation time. |
| 2024-06-18 04:03:13 +0200 | <haskellbridge> | <iqubic (she/her)> Is that intended? |
| 2024-06-18 04:03:21 +0200 | <geekosaur> | yes |
| 2024-06-18 04:03:31 +0200 | <haskellbridge> | <iqubic (she/her)> Got it. |
| 2024-06-18 04:04:52 +0200 | <haskellbridge> | <iqubic (she/her)> Also, these named scratchpads are gonna be wildly useful. It's awesome to be able to just quickly open up a terminal and have a process run in the background. Or even just being able to open up Emacs and jot down a few notes! |
| 2024-06-18 04:19:16 +0200 | <haskellbridge> | <iqubic (she/her)> Why do you have to explicitly add a manageHook for named scratchpads? |
| 2024-06-18 04:26:59 +0200 | <geekosaur> | because the manageHook is what handles all newly-opened windows, so the mini-managehooks in the scratchpad definition need to be hooked into it |
| 2024-06-18 04:28:34 +0200 | <haskellbridge> | <iqubic (she/her)> Right. I see. |
| 2024-06-18 04:30:35 +0200 | <geekosaur> | if the keybindings were part of the scratchpad definition, we could use a single combinator to hook everything in |
| 2024-06-18 04:31:12 +0200 | <geekosaur> | kinda like we have `ewmh` that hooks in everything needed for EWMH to work |
| 2024-06-18 04:31:32 +0200 | <haskellbridge> | <iqubic (she/her)> Yeah, that makes sense. |
| 2024-06-18 04:51:52 +0200 | srk | (~sorki@user/srk) |
| 2024-06-18 04:58:41 +0200 | td_ | (~td@i53870910.versanet.de) (Ping timeout: 252 seconds) |
| 2024-06-18 05:00:21 +0200 | td_ | (~td@i53870936.versanet.de) |
| 2024-06-18 05:26:49 +0200 | <haskellbridge> | <iqubic (she/her)> Did the StackSet concept come from DWM? |
| 2024-06-18 05:29:25 +0200 | <geekosaur> | I don't think so |
| 2024-06-18 05:29:56 +0200 | <geekosaur> | The StackSet is based around zippers, which are functional data structures |
| 2024-06-18 05:30:35 +0200 | <haskellbridge> | <iqubic (she/her)> Oh... DWM just has a similar concept with a master and stack. |
| 2024-06-18 05:30:55 +0200 | <geekosaur> | yeh, but I think their stack is a standard array type |
| 2024-06-18 05:31:10 +0200 | <geekosaur> | you can do arrays in functional languages, but they're a bit clunky |
| 2024-06-18 05:32:21 +0200 | <haskellbridge> | <iqubic (she/her)> Yeah, that makes sense. |
| 2024-06-18 05:32:27 +0200 | <haskellbridge> | <iqubic (she/her)> Zippers are cool! |
| 2024-06-18 05:36:21 +0200 | <geekosaur> | (re clunky: either it's immutable and messes with GC a lot, or it's mutable and everything involving it has to be in IO or ST) |
| 2024-06-18 05:41:33 +0200 | <haskellbridge> | <iqubic (she/her)> I've worked with Arrays in ST and it's painful! |
| 2024-06-18 05:44:50 +0200 | <haskellbridge> | <iqubic (she/her)> Is it possible to have the same window show up on different workspaces? |
| 2024-06-18 05:45:03 +0200 | <geekosaur> | XMonad.Actions.CopyWindow |
| 2024-06-18 05:45:25 +0200 | <geekosaur> | what does _not_ work is trying to display the same window on two screens, because X11 doesn't support it |
| 2024-06-18 05:45:47 +0200 | <geekosaur> | a compositor could do it, but no current compositor does |
| 2024-06-18 05:45:51 +0200 | <haskellbridge> | <iqubic (she/her)> Yeah... I knew about the latter caveat. |
| 2024-06-18 05:49:54 +0200 | <haskellbridge> | <iqubic (she/her)> Is there a message or function I can call to reset the state of the Tall or Mirror Tall layout after sending some Shrink or Expand messages? |
| 2024-06-18 05:50:26 +0200 | <haskellbridge> | <iqubic (she/her)> As in, reset the size of the master pane to the default. |
| 2024-06-18 05:53:56 +0200 | <geekosaur> | not specifically, I think the best you can do is reset the whole layout (`asks (layout . config) >>= setLayout`) |
| 2024-06-18 05:54:30 +0200 | <geekosaur> | (well, it only resets the current workspace at least) |
| 2024-06-18 05:55:22 +0200 | <geekosaur> | uh, `asks (layoutHook . config) >>= setLayout` |
| 2024-06-18 05:55:50 +0200 | <haskellbridge> | <iqubic (she/her)> Yeah... I was hoping to be able to reset it but stay in Tall / Mirror Tall as I was before. But it's fine. I can just reset with "M-S-<Space>" as is the default. |
| 2024-06-18 05:57:20 +0200 | <geekosaur> | I'm not sure that could even be done with a layout message, it wouldn't have access to the defaults, only its current state |
| 2024-06-18 05:58:25 +0200 | <haskellbridge> | <iqubic (she/her)> Oh... Right... |
| 2024-06-18 05:58:28 +0200 | <geekosaur> | the defaults are in the layoutHook, but that's effectively a function composed of chained data constructors so it can't be introspected to retrieve specific values from it |
| 2024-06-18 05:58:30 +0200 | <haskellbridge> | <iqubic (she/her)> I know how Haskell works... |
| 2024-06-18 05:59:01 +0200 | <haskellbridge> | <iqubic (she/her)> What does Mod Shift Space do by default? Like what action does it run? |
| 2024-06-18 05:59:33 +0200 | <geekosaur> | the one I pasted above (`asks …`) |
| 2024-06-18 06:00:07 +0200 | <geekosaur> | come to think of it,since layoutHook is composed of data constructors, you could `show` it and parse the result. it'd be a massive pain |
| 2024-06-18 06:00:38 +0200 | <geekosaur> | and if `Tall` is in it twice you probably won't be able to tell which one applies |
| 2024-06-18 06:03:28 +0200 | <haskellbridge> | <iqubic (she/her)> Yeah... that makes sense. I'd probably have to write my own version of Tall that stores the defaults if I wanted this. That's too much work.. |
| 2024-06-18 07:33:30 +0200 | <haskellbridge> | <iqubic (she/her)> Is there anywhere I can go to see how the Binary Space Partition Layout works from a user's point of view? Like, I want to know what sort of features that layout will give me. Is it trying to emulate what BSPWM is trying to do? |
| 2024-06-18 07:59:14 +0200 | <Leary> | geekosaur: Improving layout state persistence is one of the problems I used to occupy my mind with when I went for runs. On the basic side: we could keep static config in the layoutHook while storing dynamic state (of potentially another type) per workspace, and have LayoutClass provide a method to apply the dynamic changes. This should also be easy to shoehorn in as a non-breaking opt-in feature, the key change being something like: `class ... => Layout |
| 2024-06-18 07:59:15 +0200 | <Leary> | Class l a where { type Dynamic l a; type Dynamic l a = l a; apply :: Dynamic l a -> l a -> l a; default apply :: Dynamic l a ~ l a => l a -> l a -> l a; apply = const; handleMessage :: Dynamic l a -> SomeMessage -> X (Maybe (Dynamic l a)); ... }` |
| 2024-06-18 08:00:31 +0200 | <Leary> | On the advanced side, to still persist things when the layout type changes is feasible with tree-diff like techniques, but the payoff isn't enough to suffer through the complexity. |
| 2024-06-18 08:02:02 +0200 | <Leary> | Especially since, yeah, it can only achieve "best guess". |
| 2024-06-18 08:12:37 +0200 | derfflinger_ | (~derffling@user/derfflinger) |
| 2024-06-18 09:10:34 +0200 | jsoo | (~znc@irc.refl.club) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-06-18 09:10:58 +0200 | jsoo | (~jsoo@irc.refl.club) |
| 2024-06-18 09:49:13 +0200 | ft | (~ft@p3e9bcb39.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-06-18 09:51:37 +0200 | derfflinger_ | (~derffling@user/derfflinger) (Ping timeout: 255 seconds) |
| 2024-06-18 10:24:13 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-06-18 11:08:02 +0200 | redgloboli | (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2024-06-18 11:09:27 +0200 | redgloboli | (~redglobol@user/redgloboli) |
| 2024-06-18 11:09:31 +0200 | rascasse | (~rascasse@user/diep) |
| 2024-06-18 12:43:36 +0200 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 268 seconds) |
| 2024-06-18 12:44:46 +0200 | m5zs7k | (aquares@web10.mydevil.net) |
| 2024-06-18 12:45:12 +0200 | Digitteknohippie | (~user@user/digit) |
| 2024-06-18 12:46:59 +0200 | Digit | (~user@user/digit) (Ping timeout: 268 seconds) |
| 2024-06-18 12:56:45 +0200 | Digitteknohippie | Digit |
| 2024-06-18 13:30:28 +0200 | todi_away | (~todi@p57803331.dip0.t-ipconnect.de) |
| 2024-06-18 13:31:22 +0200 | gauge_ | (~gauge@45.32.227.222) |
| 2024-06-18 13:31:27 +0200 | srk- | (~sorki@user/srk) |
| 2024-06-18 13:32:59 +0200 | weitcis_ | (~quassel@syn-076-082-169-160.res.spectrum.com) |
| 2024-06-18 13:33:00 +0200 | derfflinger_ | (~derffling@user/derfflinger) |
| 2024-06-18 13:36:41 +0200 | srk | (~sorki@user/srk) (*.net *.split) |
| 2024-06-18 13:36:41 +0200 | weitcis | (~quassel@syn-076-082-169-160.res.spectrum.com) (*.net *.split) |
| 2024-06-18 13:36:41 +0200 | gauge | (~gauge@user/gauge) (*.net *.split) |
| 2024-06-18 13:36:41 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) (*.net *.split) |
| 2024-06-18 13:36:42 +0200 | liskin | (~liskin@xmonad/liskin) (*.net *.split) |
| 2024-06-18 13:36:42 +0200 | pl | (sid98063@id-98063.helmsley.irccloud.com) (*.net *.split) |
| 2024-06-18 13:36:42 +0200 | fizzie | (~irc@selene.zem.fi) (*.net *.split) |
| 2024-06-18 13:36:42 +0200 | xacktm | (xacktm@user/xacktm) (*.net *.split) |
| 2024-06-18 13:36:45 +0200 | srk- | srk |
| 2024-06-18 13:38:41 +0200 | derfflinger__ | (~derffling@user/derfflinger) |
| 2024-06-18 13:42:50 +0200 | derfflinger_ | (~derffling@user/derfflinger) (Ping timeout: 252 seconds) |
| 2024-06-18 13:44:23 +0200 | liskin | (~liskin@xmonad/liskin) |
| 2024-06-18 13:44:23 +0200 | pl | (sid98063@id-98063.helmsley.irccloud.com) |
| 2024-06-18 13:44:23 +0200 | fizzie | (~irc@selene.zem.fi) |
| 2024-06-18 13:44:23 +0200 | xacktm | (xacktm@user/xacktm) |
| 2024-06-18 14:15:39 +0200 | liskin | (~liskin@xmonad/liskin) (*.net *.split) |
| 2024-06-18 14:15:39 +0200 | pl | (sid98063@id-98063.helmsley.irccloud.com) (*.net *.split) |
| 2024-06-18 14:15:39 +0200 | fizzie | (~irc@selene.zem.fi) (*.net *.split) |
| 2024-06-18 14:15:39 +0200 | xacktm | (xacktm@user/xacktm) (*.net *.split) |
| 2024-06-18 14:17:07 +0200 | liskin | (~liskin@xmonad/liskin) |
| 2024-06-18 14:17:07 +0200 | pl | (sid98063@id-98063.helmsley.irccloud.com) |
| 2024-06-18 14:17:07 +0200 | fizzie | (~irc@selene.zem.fi) |
| 2024-06-18 14:17:07 +0200 | xacktm | (xacktm@user/xacktm) |
| 2024-06-18 14:19:15 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 260 seconds) |
| 2024-06-18 14:37:40 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-06-18 14:54:09 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 256 seconds) |
| 2024-06-18 15:22:15 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-06-18 15:25:41 +0200 | td_ | (~td@i53870936.versanet.de) (Quit: waking up from the american dream ...) |
| 2024-06-18 15:30:21 +0200 | td_ | (~td@i53870936.versanet.de) |
| 2024-06-18 16:24:41 +0200 | todi_away | todi |
| 2024-06-18 16:31:09 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 268 seconds) |
| 2024-06-18 17:56:07 +0200 | <geekosaur> | @iqubic, yes re BSP |
| 2024-06-18 17:56:07 +0200 | <lambdabot> | Unknown command, try @list |
| 2024-06-18 17:56:54 +0200 | <geekosaur> | we have a ticket to provide that kind of thing for layouts as part of upgrading the config archive, but it's stalled 😞 |
| 2024-06-18 18:17:32 +0200 | <haskellbridge> | <iqubic (she/her)> What do you mean by "yes re BSP"? |
| 2024-06-18 18:35:50 +0200 | <geekosaur> | [18 05:33:30] <haskellbridge> <iqubic (she/her)> Is there anywhere I can go to see how the Binary Space Partition Layout works from a user's point of view? Like, I want to know what sort of features that layout will give me. Is it trying to emulate what BSPWM is trying to do? |
| 2024-06-18 18:37:50 +0200 | <haskellbridge> | <iqubic (she/her)> Ah. Makes sense. I prefer automatic tiling layouts myself. I don't feel the need to micromanage my windows and where they go. |
| 2024-06-18 18:40:56 +0200 | <geekosaur> | it does autotile, but it also gives you the ability to rearrange its partitions |
| 2024-06-18 18:41:53 +0200 | <haskellbridge> | <iqubic (she/her)> How many windows do you have open on each workspace, on average? |
| 2024-06-18 18:57:03 +0200 | derfflinger__ | (~derffling@user/derfflinger) (Read error: Connection reset by peer) |
| 2024-06-18 19:43:48 +0200 | rascasse | (~rascasse@user/diep) (Ping timeout: 255 seconds) |
| 2024-06-18 19:50:52 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-06-18 21:33:11 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.2.2) |
| 2024-06-18 21:46:16 +0200 | rascasse | (~rascasse@user/diep) |
| 2024-06-18 23:32:15 +0200 | Leary | (~Leary@user/Leary/x-0910699) (Remote host closed the connection) |