| 2024-06-18 00:00:56 +0000 | <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 00:02:09 +0000 | <haskellbridge> | <iqubic (she/her)> Well, I'm just gonna be passing this RationalRect into "customFloat" to place my Named Scratch Pad. |
| 2024-06-18 01:48:00 +0000 | <haskellbridge> | <iqubic (she/her)> Does something like this work for doing scratchpad manage hooks? https://dpaste.com/3E3T9BR7J |
| 2024-06-18 01:49:16 +0000 | <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 01:51:47 +0000 | <geekosaur> | it should |
| 2024-06-18 01:52:23 +0000 | <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 01:53:08 +0000 | <haskellbridge> | <iqubic (she/her)> I am just messing with these numbers until I get something that looks good to me. |
| 2024-06-18 01:53:29 +0000 | <haskellbridge> | <iqubic (she/her)> But that should make the windows centered right? |
| 2024-06-18 01:56:05 +0000 | <geekosaur> | it should, yes |
| 2024-06-18 01:57:06 +0000 | <haskellbridge> | <iqubic (she/her)> Just checking that I got my math right. |
| 2024-06-18 01:59:11 +0000 | <haskellbridge> | <iqubic (she/her)> Is 222 lines of xmonad config too much? |
| 2024-06-18 02:00:15 +0000 | <geekosaur> | I have just over 450 😛 |
| 2024-06-18 02:01:24 +0000 | <haskellbridge> | <iqubic (she/her)> Will longer config mean slower WM? |
| 2024-06-18 02:01:34 +0000 | <geekosaur> | not necessarily |
| 2024-06-18 02:02:06 +0000 | <geekosaur> | if you have a lot of handleEventHooks or a large logHook, you may have issues |
| 2024-06-18 02:02:37 +0000 | <geekosaur> | a large keymap, for example, won't slow things down because it's compiled to (possibly nested) maps |
| 2024-06-18 02:03:07 +0000 | <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 02:03:13 +0000 | <haskellbridge> | <iqubic (she/her)> Is that intended? |
| 2024-06-18 02:03:21 +0000 | <geekosaur> | yes |
| 2024-06-18 02:03:31 +0000 | <haskellbridge> | <iqubic (she/her)> Got it. |
| 2024-06-18 02:04:52 +0000 | <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 02:19:16 +0000 | <haskellbridge> | <iqubic (she/her)> Why do you have to explicitly add a manageHook for named scratchpads? |
| 2024-06-18 02:26:59 +0000 | <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 02:28:34 +0000 | <haskellbridge> | <iqubic (she/her)> Right. I see. |
| 2024-06-18 02:30:35 +0000 | <geekosaur> | if the keybindings were part of the scratchpad definition, we could use a single combinator to hook everything in |
| 2024-06-18 02:31:12 +0000 | <geekosaur> | kinda like we have `ewmh` that hooks in everything needed for EWMH to work |
| 2024-06-18 02:31:32 +0000 | <haskellbridge> | <iqubic (she/her)> Yeah, that makes sense. |
| 2024-06-18 02:51:52 +0000 | srk | (~sorki@user/srk) |
| 2024-06-18 02:58:41 +0000 | td_ | (~td@i53870910.versanet.de) (Ping timeout: 252 seconds) |
| 2024-06-18 03:00:21 +0000 | td_ | (~td@i53870936.versanet.de) |
| 2024-06-18 03:26:49 +0000 | <haskellbridge> | <iqubic (she/her)> Did the StackSet concept come from DWM? |
| 2024-06-18 03:29:25 +0000 | <geekosaur> | I don't think so |
| 2024-06-18 03:29:56 +0000 | <geekosaur> | The StackSet is based around zippers, which are functional data structures |
| 2024-06-18 03:30:35 +0000 | <haskellbridge> | <iqubic (she/her)> Oh... DWM just has a similar concept with a master and stack. |
| 2024-06-18 03:30:55 +0000 | <geekosaur> | yeh, but I think their stack is a standard array type |
| 2024-06-18 03:31:10 +0000 | <geekosaur> | you can do arrays in functional languages, but they're a bit clunky |
| 2024-06-18 03:32:21 +0000 | <haskellbridge> | <iqubic (she/her)> Yeah, that makes sense. |
| 2024-06-18 03:32:27 +0000 | <haskellbridge> | <iqubic (she/her)> Zippers are cool! |
| 2024-06-18 03:36:21 +0000 | <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 03:41:33 +0000 | <haskellbridge> | <iqubic (she/her)> I've worked with Arrays in ST and it's painful! |
| 2024-06-18 03:44:50 +0000 | <haskellbridge> | <iqubic (she/her)> Is it possible to have the same window show up on different workspaces? |
| 2024-06-18 03:45:03 +0000 | <geekosaur> | XMonad.Actions.CopyWindow |
| 2024-06-18 03:45:25 +0000 | <geekosaur> | what does _not_ work is trying to display the same window on two screens, because X11 doesn't support it |
| 2024-06-18 03:45:47 +0000 | <geekosaur> | a compositor could do it, but no current compositor does |
| 2024-06-18 03:45:51 +0000 | <haskellbridge> | <iqubic (she/her)> Yeah... I knew about the latter caveat. |
| 2024-06-18 03:49:54 +0000 | <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 03:50:26 +0000 | <haskellbridge> | <iqubic (she/her)> As in, reset the size of the master pane to the default. |
| 2024-06-18 03:53:56 +0000 | <geekosaur> | not specifically, I think the best you can do is reset the whole layout (`asks (layout . config) >>= setLayout`) |
| 2024-06-18 03:54:30 +0000 | <geekosaur> | (well, it only resets the current workspace at least) |
| 2024-06-18 03:55:22 +0000 | <geekosaur> | uh, `asks (layoutHook . config) >>= setLayout` |
| 2024-06-18 03:55:50 +0000 | <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 03:57:20 +0000 | <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 03:58:25 +0000 | <haskellbridge> | <iqubic (she/her)> Oh... Right... |
| 2024-06-18 03:58:28 +0000 | <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 03:58:30 +0000 | <haskellbridge> | <iqubic (she/her)> I know how Haskell works... |
| 2024-06-18 03:59:01 +0000 | <haskellbridge> | <iqubic (she/her)> What does Mod Shift Space do by default? Like what action does it run? |
| 2024-06-18 03:59:33 +0000 | <geekosaur> | the one I pasted above (`asks …`) |
| 2024-06-18 04:00:07 +0000 | <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 04:00:38 +0000 | <geekosaur> | and if `Tall` is in it twice you probably won't be able to tell which one applies |
| 2024-06-18 04:03:28 +0000 | <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 05:33:30 +0000 | <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 05:59:14 +0000 | <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 05:59:15 +0000 | <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 06:00:31 +0000 | <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 06:02:02 +0000 | <Leary> | Especially since, yeah, it can only achieve "best guess". |
| 2024-06-18 06:12:37 +0000 | derfflinger_ | (~derffling@user/derfflinger) |
| 2024-06-18 07:10:34 +0000 | jsoo | (~znc@irc.refl.club) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-06-18 07:10:58 +0000 | jsoo | (~jsoo@irc.refl.club) |
| 2024-06-18 07:49:13 +0000 | ft | (~ft@p3e9bcb39.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-06-18 07:51:37 +0000 | derfflinger_ | (~derffling@user/derfflinger) (Ping timeout: 255 seconds) |
| 2024-06-18 08:24:13 +0000 | cfricke | (~cfricke@user/cfricke) |
| 2024-06-18 09:08:02 +0000 | redgloboli | (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2024-06-18 09:09:27 +0000 | redgloboli | (~redglobol@user/redgloboli) |
| 2024-06-18 09:09:31 +0000 | rascasse | (~rascasse@user/diep) |
| 2024-06-18 10:43:36 +0000 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 268 seconds) |
| 2024-06-18 10:44:46 +0000 | m5zs7k | (aquares@web10.mydevil.net) |
| 2024-06-18 10:45:12 +0000 | Digitteknohippie | (~user@user/digit) |
| 2024-06-18 10:46:59 +0000 | Digit | (~user@user/digit) (Ping timeout: 268 seconds) |
| 2024-06-18 10:56:45 +0000 | Digitteknohippie | Digit |
| 2024-06-18 11:30:28 +0000 | todi_away | (~todi@p57803331.dip0.t-ipconnect.de) |
| 2024-06-18 11:31:22 +0000 | gauge_ | (~gauge@45.32.227.222) |
| 2024-06-18 11:31:27 +0000 | srk- | (~sorki@user/srk) |
| 2024-06-18 11:32:59 +0000 | weitcis_ | (~quassel@syn-076-082-169-160.res.spectrum.com) |
| 2024-06-18 11:33:00 +0000 | derfflinger_ | (~derffling@user/derfflinger) |
| 2024-06-18 11:36:41 +0000 | srk | (~sorki@user/srk) (*.net *.split) |
| 2024-06-18 11:36:41 +0000 | weitcis | (~quassel@syn-076-082-169-160.res.spectrum.com) (*.net *.split) |
| 2024-06-18 11:36:41 +0000 | gauge | (~gauge@user/gauge) (*.net *.split) |
| 2024-06-18 11:36:41 +0000 | todi | (~todi@p57803331.dip0.t-ipconnect.de) (*.net *.split) |
| 2024-06-18 11:36:42 +0000 | liskin | (~liskin@xmonad/liskin) (*.net *.split) |
| 2024-06-18 11:36:42 +0000 | pl | (sid98063@id-98063.helmsley.irccloud.com) (*.net *.split) |
| 2024-06-18 11:36:42 +0000 | fizzie | (~irc@selene.zem.fi) (*.net *.split) |
| 2024-06-18 11:36:42 +0000 | xacktm | (xacktm@user/xacktm) (*.net *.split) |
| 2024-06-18 11:36:45 +0000 | srk- | srk |
| 2024-06-18 11:38:41 +0000 | derfflinger__ | (~derffling@user/derfflinger) |
| 2024-06-18 11:42:50 +0000 | derfflinger_ | (~derffling@user/derfflinger) (Ping timeout: 252 seconds) |
| 2024-06-18 11:44:23 +0000 | liskin | (~liskin@xmonad/liskin) |
| 2024-06-18 11:44:23 +0000 | pl | (sid98063@id-98063.helmsley.irccloud.com) |
| 2024-06-18 11:44:23 +0000 | fizzie | (~irc@selene.zem.fi) |
| 2024-06-18 11:44:23 +0000 | xacktm | (xacktm@user/xacktm) |
| 2024-06-18 12:15:39 +0000 | liskin | (~liskin@xmonad/liskin) (*.net *.split) |
| 2024-06-18 12:15:39 +0000 | pl | (sid98063@id-98063.helmsley.irccloud.com) (*.net *.split) |
| 2024-06-18 12:15:39 +0000 | fizzie | (~irc@selene.zem.fi) (*.net *.split) |
| 2024-06-18 12:15:39 +0000 | xacktm | (xacktm@user/xacktm) (*.net *.split) |
| 2024-06-18 12:17:07 +0000 | liskin | (~liskin@xmonad/liskin) |
| 2024-06-18 12:17:07 +0000 | pl | (sid98063@id-98063.helmsley.irccloud.com) |
| 2024-06-18 12:17:07 +0000 | fizzie | (~irc@selene.zem.fi) |
| 2024-06-18 12:17:07 +0000 | xacktm | (xacktm@user/xacktm) |
| 2024-06-18 12:19:15 +0000 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 260 seconds) |
| 2024-06-18 12:37:40 +0000 | cfricke | (~cfricke@user/cfricke) |
| 2024-06-18 12:54:09 +0000 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 256 seconds) |
| 2024-06-18 13:22:15 +0000 | cfricke | (~cfricke@user/cfricke) |
| 2024-06-18 13:25:41 +0000 | td_ | (~td@i53870936.versanet.de) (Quit: waking up from the american dream ...) |
| 2024-06-18 13:30:21 +0000 | td_ | (~td@i53870936.versanet.de) |
| 2024-06-18 14:24:41 +0000 | todi_away | todi |
| 2024-06-18 14:31:09 +0000 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 268 seconds) |
| 2024-06-18 15:56:07 +0000 | <geekosaur> | @iqubic, yes re BSP |
| 2024-06-18 15:56:07 +0000 | <lambdabot> | Unknown command, try @list |
| 2024-06-18 15:56:54 +0000 | <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 16:17:32 +0000 | <haskellbridge> | <iqubic (she/her)> What do you mean by "yes re BSP"? |
| 2024-06-18 16:35:50 +0000 | <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 16:37:50 +0000 | <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 16:40:56 +0000 | <geekosaur> | it does autotile, but it also gives you the ability to rearrange its partitions |
| 2024-06-18 16:41:53 +0000 | <haskellbridge> | <iqubic (she/her)> How many windows do you have open on each workspace, on average? |
| 2024-06-18 16:57:03 +0000 | derfflinger__ | (~derffling@user/derfflinger) (Read error: Connection reset by peer) |
| 2024-06-18 17:43:48 +0000 | rascasse | (~rascasse@user/diep) (Ping timeout: 255 seconds) |
| 2024-06-18 17:50:52 +0000 | cfricke | (~cfricke@user/cfricke) |
| 2024-06-18 19:33:11 +0000 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.2.2) |
| 2024-06-18 19:46:16 +0000 | rascasse | (~rascasse@user/diep) |
| 2024-06-18 21:32:15 +0000 | Leary | (~Leary@user/Leary/x-0910699) (Remote host closed the connection) |
| 2024-06-18 22:25:27 +0000 | ft | (~ft@p3e9bcb39.dip0.t-ipconnect.de) |
| 2024-06-18 23:23:40 +0000 | rascasse | (~rascasse@user/diep) (Remote host closed the connection) |