| 2025-08-13 00:44:56 +0200 | Leary | (~Leary@user/Leary/x-0910699) (Remote host closed the connection) |
| 2025-08-13 00:48:41 +0200 | Leary | (~Leary@user/Leary/x-0910699) Leary |
| 2025-08-13 02:48:43 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection timed out) |
| 2025-08-13 03:20:31 +0200 | catman | (~catman@user/catman) (Quit: WeeChat 4.7.0) |
| 2025-08-13 04:03:13 +0200 | ft | (~ft@p4fc2aa9f.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2025-08-13 04:04:57 +0200 | ft | (~ft@p3e9bc646.dip0.t-ipconnect.de) ft |
| 2025-08-13 04:12:40 +0200 | td_ | (~td@i53870915.versanet.de) (Ping timeout: 255 seconds) |
| 2025-08-13 04:14:17 +0200 | td_ | (~td@i5387090d.versanet.de) td_ |
| 2025-08-13 05:58:47 +0200 | ft | (~ft@p3e9bc646.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-08-13 06:05:34 +0200 | ft | (~ft@p508dbd3a.dip0.t-ipconnect.de) ft |
| 2025-08-13 06:11:37 +0200 | ft | (~ft@p508dbd3a.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-08-13 06:13:24 +0200 | ft | (~ft@p508dbd4a.dip0.t-ipconnect.de) ft |
| 2025-08-13 06:18:37 +0200 | ft | (~ft@p508dbd4a.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-08-13 06:19:23 +0200 | ft | (~ft@p508dbdda.dip0.t-ipconnect.de) ft |
| 2025-08-13 07:46:16 +0200 | ft | (~ft@p508dbdda.dip0.t-ipconnect.de) (Ping timeout: 276 seconds) |
| 2025-08-13 07:47:28 +0200 | ft | (~ft@p508dbaa3.dip0.t-ipconnect.de) ft |
| 2025-08-13 08:13:00 +0200 | gwentpl | (~gwpl@user/gwentpl) (Ping timeout: 276 seconds) |
| 2025-08-13 08:25:56 +0200 | ft | (~ft@p508dbaa3.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-08-13 08:32:33 +0200 | gwentpl | (~gwpl@user/gwentpl) gwentpl |
| 2025-08-13 08:32:50 +0200 | ft | (~ft@p508dbd8e.dip0.t-ipconnect.de) ft |
| 2025-08-13 08:46:25 +0200 | gwentpl | (~gwpl@user/gwentpl) (Read error: Connection reset by peer) |
| 2025-08-13 08:46:33 +0200 | spwl | (~gwpl@user/gwentpl) gwentpl |
| 2025-08-13 09:18:40 +0200 | spwl | (~gwpl@user/gwentpl) (Ping timeout: 255 seconds) |
| 2025-08-13 09:18:50 +0200 | gwentpl | (~gwpl@user/gwentpl) gwentpl |
| 2025-08-13 09:49:20 +0200 | ft | (~ft@p508dbd8e.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-08-13 11:49:08 +0200 | ChubaDuba | (~ChubaDuba@109.195.235.119) ChubaDuba |
| 2025-08-13 12:25:18 +0200 | ChubaDuba | (~ChubaDuba@109.195.235.119) (Quit: WeeChat 4.6.3) |
| 2025-08-13 13:53:22 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-08-13 16:17:22 +0200 | catman | (~catman@user/catman) catman |
| 2025-08-13 17:34:45 +0200 | ft | (~ft@p508dbd8e.dip0.t-ipconnect.de) ft |
| 2025-08-13 18:10:49 +0200 | samhh_ | samhh |
| 2025-08-13 22:22:21 +0200 | <haskellbridge> | <iqubic (she/her)> Why is screen sharing weird on XMonad? Basically, when an application wants to screen share, it gives me two options "entire screen" or "select window" However, the "select window" option seems to only ever list windows that are visible. Like, even if I'm in the Full layout and have multiple applications on the current workspace, I still only see the option for the window at the top of the stack. |
| 2025-08-13 22:23:20 +0200 | <geekosaur> | try using Simplest instead of Full |
| 2025-08-13 22:23:37 +0200 | <geekosaur> | xmonad unmaps invisible windows ormally, which renders them inaccessible to other apps |
| 2025-08-13 22:23:51 +0200 | <geekosaur> | most other window managers leave them mapped but move them offscreen |
| 2025-08-13 22:24:10 +0200 | <haskellbridge> | <iqubic (she/her)> What does Simplest do? |
| 2025-08-13 22:24:52 +0200 | <geekosaur> | Full only provides a rectangle for the topmost window, so the others get unmapped. Simplest provides rectangles for all windows on the current workspace, so they're mapped but hidden under the topmost window |
| 2025-08-13 22:25:13 +0200 | <haskellbridge> | <iqubic (she/her)> Oh, I see. |
| 2025-08-13 22:26:25 +0200 | <geekosaur> | this also breaks some extensions (notably the tabbed family), which is why Simplest exists |
| 2025-08-13 22:26:58 +0200 | <geekosaur> | specifically, you would get a tab only for the topmost window with Tabbed Full |
| 2025-08-13 22:27:23 +0200 | <haskellbridge> | <iqubic (she/her)> Is there any downside to using Simplest everywhere instead of Full? |
| 2025-08-13 22:27:40 +0200 | <haskellbridge> | <iqubic (she/her)> Also will using Simplest break NamedScratchpads? |
| 2025-08-13 22:28:10 +0200 | <geekosaur> | a little bit of a slowdown and a little more memory used, but in both cases you'd be getting the same thing other window managers do and the differences aren't enough to notice |
| 2025-08-13 22:29:16 +0200 | <geekosaur> | NamedScratchpads doesn't care, because they're floats and therefore not managed by the layout (trying to use tiled windows as scratchpads will behave very oddly regardless) |
| 2025-08-13 22:30:38 +0200 | <geekosaur> | tabbed (and other layout modifiers that associate additional windows, as for example DwmStyle) will only assign their windows to mapped windows |
| 2025-08-13 22:31:37 +0200 | <haskellbridge> | <iqubic (she/her)> Got it. And Full only maps the top window in the stack? |
| 2025-08-13 22:31:52 +0200 | <haskellbridge> | <iqubic (she/her)> That's the main difference when compared with Simplest? |
| 2025-08-13 22:31:58 +0200 | <geekosaur> | correct, by only returning a rectangle for that window |
| 2025-08-13 22:32:53 +0200 | <geekosaur> | layouts are given a list of windows and a screen region, and produce a list of rectangles saying where the windows are to be positioned/sized. any window not assigned a rectangle gets unmapped |
| 2025-08-13 22:34:24 +0200 | <haskellbridge> | <iqubic (she/her)> Right. I see. What happens when XMonad is told to render multiple windows in overlapping locations? |
| 2025-08-13 22:36:07 +0200 | <geekosaur> | it does so, and the X server draws whatever is visible based on the reverse order of mapping (so the last one mapped is topmost) |
| 2025-08-13 22:36:41 +0200 | <geekosaur> | in essence, you're putting windows on top of each other |
| 2025-08-13 22:38:08 +0200 | <haskellbridge> | <iqubic (she/her)> I find it funny that Simplest is actually more code than Full, because Full just seems to be using the default implementations from the LayoutClass class |
| 2025-08-13 22:38:38 +0200 | <haskellbridge> | <iqubic (she/her)> Literally the code is just "instance LayoutClass Full a" |
| 2025-08-13 22:38:41 +0200 | <haskellbridge> | <iqubic (she/her)> vs |
| 2025-08-13 22:39:16 +0200 | <haskellbridge> | <iqubic (she/her)> I love how the default is to only map visible windows. |
| 2025-08-13 22:42:23 +0200 | <geekosaur> | well, aside from the fact that it completely breaks screen sharing utilities and a few other similar things that want access to the contents of hidden windows |
| 2025-08-13 22:42:54 +0200 | <haskellbridge> | <iqubic (she/her)> Yeah. I get that. |
| 2025-08-13 22:43:10 +0200 | <haskellbridge> | <iqubic (she/her)> Simplest is what I want. Let me see if that works. |
| 2025-08-13 22:43:10 +0200 | <geekosaur> | and yes, Full is just the default. which is also why if something goes wrong in your layout for some reason (e.g. it throws an exception), xmonad degrades to Full (actually, the default implementation) |
| 2025-08-13 22:47:27 +0200 | samhh | (7569f027cf@2a03:6000:1812:100::e4) (Server closed connection) |
| 2025-08-13 22:47:36 +0200 | samhh_ | (7569f027cf@2a03:6000:1812:100::e4) samhh |
| 2025-08-13 22:48:21 +0200 | <haskellbridge> | <iqubic (she/her)> If workspace 1 is set to Simplest and workspace 2 is set to Tall and workspace 2 is currently focused, will that still unmap the windows on workspace 1? |
| 2025-08-13 22:48:50 +0200 | <geekosaur> | if it's not visible (i.e. multi-monitor) |
| 2025-08-13 22:49:05 +0200 | <haskellbridge> | <iqubic (she/her)> Like, does setting a workspace to the layout "simplest" prevent the windows from being unmapped when the workspace isn't visible? |
| 2025-08-13 22:49:48 +0200 | <geekosaur> | that's the case where other window managers move things offscreen instead so they're still mapped and therefore contents available to other programs |
| 2025-08-13 22:50:16 +0200 | <haskellbridge> | <iqubic (she/her)> Ah. I see. I can work with this. |
| 2025-08-13 22:50:25 +0200 | <geekosaur> | this is probably something we should consider changing, although I think Full needs to keep its current behavior |
| 2025-08-13 22:51:50 +0200 | <haskellbridge> | <iqubic (she/her)> It would be a big change though. |
| 2025-08-13 22:53:07 +0200 | <geekosaur> | I don't think it would actually be that big. XMonad.Operations.windows would need to change what it's doing, but that would be invisible to everything but v4l or XImage consumers |
| 2025-08-13 22:55:51 +0200 | <geekosaur> | layout modifiers would still go by the windows inbound and rectangles outbound, map state is irrelevant (and must be because it all happens _before_ the result is displayed) |
| 2025-08-13 22:58:51 +0200 | <haskellbridge> | <iqubic (she/her)> Interesting. I'm not sure how useful this change would be. |
| 2025-08-13 22:59:21 +0200 | <haskellbridge> | <iqubic (she/her)> Simplest works well enough for me. |
| 2025-08-13 23:18:26 +0200 | <haskellbridge> | <iqubic (she/her)> Is there a way to modify a layout to never have an boarders? |
| 2025-08-13 23:20:01 +0200 | <haskellbridge> | <iqubic (she/her)> I have this: https://github.com/IQubic/nixos-config/blob/master/hm/xmonad/XMonad.hs#L88-L103 |
| 2025-08-13 23:20:20 +0200 | <geekosaur> | https://hackage.haskell.org/package/xmonad-contrib-0.18.1/docs/XMonad-Layout-NoBorders.html https://hackage.haskell.org/package/xmonad-contrib-0.18.1/docs/XMonad-Layout-VoidBorders.html (different behaviors) |
| 2025-08-13 23:20:29 +0200 | <haskellbridge> | <iqubic (she/her)> layoutHook = avoidStruts $ smartBorders $ windowNavigation $ myLayoutHook |
| 2025-08-13 23:21:02 +0200 | <haskellbridge> | <iqubic (she/her)> The thing I want to do is make it so that the Simplest Layout doesn't have ever have any boarders. |
| 2025-08-13 23:21:17 +0200 | <haskellbridge> | <iqubic (she/her)> But I'm not sure how to modify my layout to do that. |
| 2025-08-13 23:21:37 +0200 | <geekosaur> | NoBorders Simplest |
| 2025-08-13 23:21:59 +0200 | <haskellbridge> | <iqubic (she/her)> Will there be a conflict with smartBoarders at the bottom of the file? |
| 2025-08-13 23:22:06 +0200 | <geekosaur> | sorry, make that noBorders Simplest |
| 2025-08-13 23:23:07 +0200 | <geekosaur> | yesit'll override the smartBorders behavior, at the possible price of border "flashing" on changing workspaces |
| 2025-08-13 23:23:17 +0200 | <geekosaur> | -yes |
| 2025-08-13 23:23:46 +0200 | <haskellbridge> | <iqubic (she/her)> Interesting. That's fine. |
| 2025-08-13 23:29:55 +0200 | <haskellbridge> | <iqubic (she/her)> I'm actually not getting any border flashing. |