[BUG]: Some applications resize off-screen #386

@CtByte commented on GitHub (May 21, 2024):

May I ask which layout you tested on?

This is how it looks on BSP

I am on the 69680b4 commit

@CtByte commented on GitHub (May 21, 2024): May I ask which layout you tested on? This is how it looks on BSP ![image](https://github.com/LGUG2Z/komorebi/assets/165908630/b2cece63-915b-4ff7-8e63-cfb054b58b3f) I am on the 69680b4 commit

adam commented

https://github.com/LGUG2Z/komorebi/assets/52843537/7f055d71-6646-4314-bcea-1d792ab5f0a8

@Insprill commented on GitHub (May 21, 2024):

I don't have any set, so it's the default, which I believe is BSP. I updated to 69680b4238 and the issue is still present.

I did a little more testing, and it appears like sometimes it'll tile correctly. I recorded a video showcasing the inconsistency. You can see it tiles correctly in the left and bottom-middle slots, but it goes "out-of-bounds" in the top-right and bottom-right.

@Insprill commented on GitHub (May 21, 2024): I don't have any set, so it's the default, which I believe is BSP. I updated to 69680b423840bc0c54b3b6f948adff7d1a25918f and the issue is still present. I did a little more testing, and it appears like *sometimes* it'll tile correctly. I recorded a video showcasing the inconsistency. You can see it tiles correctly in the left and bottom-middle slots, but it goes "out-of-bounds" in the top-right and bottom-right. https://github.com/LGUG2Z/komorebi/assets/52843537/7f055d71-6646-4314-bcea-1d792ab5f0a8

adam commented

@CtByte commented on GitHub (May 21, 2024):

Could it be something with your border and spacing settings? I tried to move with console and mouse and could not break it.

This is what I have

  "$schema": "https://raw.githubusercontent.com/LGUG2Z/komorebi/v0.1.22/schema.json",
  "app_specific_configuration_path": "$Env:USERPROFILE/applications.yaml",
  "window_hiding_behaviour": "Cloak",
  "unmanaged_window_operation_behaviour": "Op",
  "cross_monitor_move_behaviour": "Insert",
  "default_workspace_padding": 5,
  "default_container_padding": 5,
  "border_padding": 5,
  "border_offset": -1,
  "active_window_border": false,
  "active_window_border_style": "Rounded",
  "active_window_border_colours": {
    "single": "#42a5f5",
    "stack": "#00a542",
    "monocle": "#ff3399"
  },
[...]

Would it also break if you open file explorer windows instead of the powershell? I really hope we can narrow it down a bit :)

@CtByte commented on GitHub (May 21, 2024): Could it be something with your border and spacing settings? I tried to move with console and mouse and could not break it. This is what I have ``` "$schema": "https://raw.githubusercontent.com/LGUG2Z/komorebi/v0.1.22/schema.json", "app_specific_configuration_path": "$Env:USERPROFILE/applications.yaml", "window_hiding_behaviour": "Cloak", "unmanaged_window_operation_behaviour": "Op", "cross_monitor_move_behaviour": "Insert", "default_workspace_padding": 5, "default_container_padding": 5, "border_padding": 5, "border_offset": -1, "active_window_border": false, "active_window_border_style": "Rounded", "active_window_border_colours": { "single": "#42a5f5", "stack": "#00a542", "monocle": "#ff3399" }, [...] ``` Would it also break if you open file explorer windows instead of the powershell? I really hope we can narrow it down a bit :)

adam commented

@Insprill commented on GitHub (May 21, 2024):

It'll break while tiled with any application. I tested with Explorer, Firefox, and Alacritty.

My Komorebi config can be found on GitHub. I'm not currently running Zebar, and I'm not testing on the first workspace with the layout set (tested on 3, 4, and 5)
https://github.com/Insprill/dotfiles/blob/master/komorebi.json

I do have three monitors, with one of them vertical, so maybe it's related to that?

@Insprill commented on GitHub (May 21, 2024): It'll break while tiled with any application. I tested with Explorer, Firefox, and Alacritty. My Komorebi config can be found on GitHub. I'm not currently running Zebar, and I'm not testing on the first workspace with the layout set (tested on 3, 4, and 5) https://github.com/Insprill/dotfiles/blob/master/komorebi.json I do have three monitors, with one of them vertical, so maybe it's related to that? ![image](https://github.com/LGUG2Z/komorebi/assets/52843537/9a9d21d3-a1c5-4a63-a7a5-4c860087094d)

adam commented

@CtByte commented on GitHub (May 21, 2024):

That is a good question, I did try again with your settings, but it did not break. I have 2 identical monitors with the same resolution.

I was just hoping we could narrow down the use case for the bug, but we might need to wait for someone else to test or you might need to dig a bit deeper.

I did have some bugs myself that LGUG2Z could not reproduce, but he gave me good ways to test this on my own. Perhaps he has a better way to test this, maybe using the gui?

Sorry I could not be more help :(

@CtByte commented on GitHub (May 21, 2024): That is a good question, I did try again with your settings, but it did not break. I have 2 identical monitors with the same resolution. I was just hoping we could narrow down the use case for the bug, but we might need to wait for someone else to test or you might need to dig a bit deeper. I did have some bugs myself that LGUG2Z could not reproduce, but he gave me good ways to test this on my own. Perhaps he has a better way to test this, maybe using the `gui`? Sorry I could not be more help :(

adam commented

@Insprill commented on GitHub (May 21, 2024):

I did a bit more testing, and it's definitely a monitor issue. Turning off my right monitor fixes it, and turning it back on causes the issue again. I cannot reproduce it with the right monitor off and the left configured the same as the right. Setting up the right monitor the same as the left also does not fix the problem. I tried swapping which ports the monitors are plugged into, and it behaves the same. It seems that any time my right monitor is on, regardless of its configuration, the issue occurs. I'm now truly confused 😅

~~Perhaps it's driver-related? I have an AMD 7900XTX running Adrenalin v24.5.1. My primary monitor is 3440x1440@100Hz and the two side monitors are 3840x2160@60Hz.~~

@Insprill commented on GitHub (May 21, 2024): ~~I did a bit more testing, and it's definitely a monitor issue. Turning off my right monitor fixes it, and turning it back on causes the issue again. I cannot reproduce it with the right monitor off and the left configured the same as the right. Setting up the right monitor the same as the left also does not fix the problem. I tried swapping which ports the monitors are plugged into, and it behaves the same. It seems that *any time* my right monitor is on, regardless of its configuration, the issue occurs. I'm now truly confused 😅~~ ~~Perhaps it's driver-related? I have an AMD 7900XTX running Adrenalin v24.5.1. My primary monitor is 3440x1440@100Hz and the two side monitors are 3840x2160@60Hz.~~

adam commented

https://github.com/LGUG2Z/komorebi/assets/52843537/ccff73aa-1af3-44c5-ba29-f477fb788b83

@Insprill commented on GitHub (May 21, 2024):

After even more testing, I seem to have dug up a quite serious issue with monitor scaling. Here's Audacity breaking even more with two monitors, both landscape, one at 100% scale and the other at 200% scale

The issue I first reported can be reproduced with two monitors by setting the primary to 100% scale and the secondary to 125% scale, rotated portrait.

Here's Audacity stretching across two monitors when in the primary left tile on the right monitor, when the left monitor is portrait at 125% scale.

Can you try reproducing this?

@Insprill commented on GitHub (May 21, 2024): After even more testing, I seem to have dug up a quite serious issue with monitor scaling. Here's Audacity breaking even more with two monitors, both landscape, one at 100% scale and the other at 200% scale https://github.com/LGUG2Z/komorebi/assets/52843537/ccff73aa-1af3-44c5-ba29-f477fb788b83 The issue I first reported can be reproduced with two monitors by setting the primary to 100% scale and the secondary to 125% scale, rotated portrait. Here's Audacity stretching across two monitors when in the primary left tile on the right monitor, when the left monitor is portrait at 125% scale. ![IMG_1795](https://github.com/LGUG2Z/komorebi/assets/52843537/c43d4a64-be90-403d-bb31-6da969c5b0c1) Can you try reproducing this?

adam commented

@CtByte commented on GitHub (May 21, 2024):

I tried to set the 1st monitor to 100% scaling in portrait and the 2nd to 125% scaling in landscape mode. I moved audacity around with commands and mouse, but I could not break it :(

I gave it a good try, I swear.

I can see how this is quite "the pebble in your shoe". If you say that scaling makes it worse, then that helps to reproduce it at least. If it was me I would try to look at some logs, but I am not sure if you are up for that :)

@CtByte commented on GitHub (May 21, 2024): I tried to set the 1st monitor to 100% scaling in portrait and the 2nd to 125% scaling in landscape mode. I moved audacity around with commands and mouse, but I could not break it :( I gave it a good try, I swear. I can see how this is quite "the pebble in your shoe". If you say that scaling makes it worse, then that helps to reproduce it at least. If it was me I would try to look at some logs, but I am not sure if you are up for that :)

adam commented

@Insprill commented on GitHub (May 22, 2024):

It's not just that different scaling makes it worse; if all monitors are at 100% scale, the issue goes away completely. Perhaps it's also related to differing resolutions between monitors? I ran komorebic log while moving the window around through two tiles where it's broken and one when it's not. The log output is exactly the same when set to 100% and 125% scaling. Hopefully LGUG2Z can shed some light here

@Insprill commented on GitHub (May 22, 2024): It's not just that different scaling makes it worse; if all monitors are at 100% scale, the issue goes away completely. Perhaps it's also related to differing resolutions between monitors? I ran `komorebic log` while moving the window around through two tiles where it's broken and one when it's not. The log output is exactly the same when set to [100%](https://paste.insprill.net/qP8XS) and [125%](https://paste.insprill.net/9Zoq2) scaling. Hopefully LGUG2Z can shed some light here

adam commented

@LGUG2Z commented on GitHub (May 22, 2024):

I've just quickly tried Audacity with both 100% and 125% scaling on my monitor (5120x2160) and haven't been able to reproduce anything like what your videos are showing. It would be useful to check the dimensions given for that container in the state for a window that is rendering as expected and one that is rendering past its bounds 🤔

@LGUG2Z commented on GitHub (May 22, 2024): I've just quickly tried Audacity with both 100% and 125% scaling on my monitor (5120x2160) and haven't been able to reproduce anything like what your videos are showing. It would be useful to check the dimensions given for that container in the state for a window that is rendering as expected and one that is rendering past its bounds 🤔

adam commented

@Insprill commented on GitHub (May 22, 2024):

Do you have multiple monitors with different scaling, or just one? I can only reproduce it with two monitors set at different scales.

Here's the output of komorebic state for the explorer and audacity windows when it's broken

and when it's not broken

@Insprill commented on GitHub (May 22, 2024): Do you have multiple monitors with different scaling, or just one? I can only reproduce it with two monitors set at different scales. Here's the output of `komorebic state` for the explorer and audacity windows when it's broken ![image](https://github.com/LGUG2Z/komorebi/assets/52843537/84e6df3a-38d6-4972-ad1e-a17cce8f64de) and when it's not broken ![image](https://github.com/LGUG2Z/komorebi/assets/52843537/47c359f2-33c6-401b-9ff0-365b90edac0d)

adam commented

@LGUG2Z commented on GitHub (May 22, 2024):

Just tried this with two monitors connected, 5120x2160@125% and 1280x720@100%, still could not reproduce.

The Rect output in the state for each Window is actually reading directly from the Windows API, can you grab the Rects from latest_layout under the workspace?

komorebic state | jq '.monitors.elements[YOUR MONITOR INDEX].workspaces.elements[YOUR WORKSPACE INDEX].latest_layout'

Then compare this with the output for each of the windows on that workspace as reported from the Win32 API:

komorebic state | jq '.monitors.elements[YOUR MONITOR INDEX].workspaces.elements[YOUR WORKSPACE INDEX].containers.elements[].windows.elements[].rect'

Add the relevant monitor and workspace index numbers where indicated in the jq commands above ^

@LGUG2Z commented on GitHub (May 22, 2024): Just tried this with two monitors connected, 5120x2160@125% and 1280x720@100%, still could not reproduce. The Rect output in the state for each Window is actually reading directly from the Windows API, can you grab the Rects from `latest_layout` under the workspace? `komorebic state | jq '.monitors.elements[YOUR MONITOR INDEX].workspaces.elements[YOUR WORKSPACE INDEX].latest_layout'` Then compare this with the output for each of the windows on that workspace as reported from the Win32 API: `komorebic state | jq '.monitors.elements[YOUR MONITOR INDEX].workspaces.elements[YOUR WORKSPACE INDEX].containers.elements[].windows.elements[].rect'` Add the relevant monitor and workspace index numbers where indicated in the `jq` commands above ^

adam commented

@Insprill commented on GitHub (May 22, 2024):

I'm curious as both of you tested with the primary monitor scaled higher, can you repro if your primary monitor is 100% and the secondary is 125%?

First Command

Broken

[
  {
    "left": 4,
    "top": 4,
    "right": 1714,
    "bottom": 1400
  },
  {
    "left": 1722,
    "top": 4,
    "right": 1714,
    "bottom": 672
  },
  {
    "left": 1722,
    "top": 680,
    "right": 855,
    "bottom": 724
  },
  {
    "left": 2581,
    "top": 680,
    "right": 855,
    "bottom": 724
  }
]

Good

[
  {
    "left": 4,
    "top": 4,
    "right": 1714,
    "bottom": 1400
  },
  {
    "left": 1722,
    "top": 4,
    "right": 1714,
    "bottom": 672
  },
  {
    "left": 1722,
    "top": 680,
    "right": 855,
    "bottom": 724
  },
  {
    "left": 2581,
    "top": 680,
    "right": 855,
    "bottom": 724
  }
]

Second Command

Broken

{
  "left": 4,
  "top": 4,
  "right": 1714,
  "bottom": 1400
}
{
  "left": 1722,
  "top": 4,
  "right": 1714,
  "bottom": 672
}
{
  "left": 1722,
  "top": 680,
  "right": 855,
  "bottom": 724
}
{
  "left": 2581,
  "top": 255,
  "right": 854,
  "bottom": 1149
}

Good

{
  "left": 4,
  "top": 4,
  "right": 1714,
  "bottom": 1400
}
{
  "left": 1722,
  "top": 4,
  "right": 1714,
  "bottom": 672
}
{
  "left": 1722,
  "top": 680,
  "right": 855,
  "bottom": 724
}
{
  "left": 2581,
  "top": 680,
  "right": 855,
  "bottom": 724
}

@Insprill commented on GitHub (May 22, 2024): I'm curious as both of you tested with the primary monitor scaled higher, can you repro if your primary monitor is 100% and the secondary is 125%? ## First Command <details> <summary>Broken</summary> ```json [ { "left": 4, "top": 4, "right": 1714, "bottom": 1400 }, { "left": 1722, "top": 4, "right": 1714, "bottom": 672 }, { "left": 1722, "top": 680, "right": 855, "bottom": 724 }, { "left": 2581, "top": 680, "right": 855, "bottom": 724 } ] ``` </details> <details> <summary>Good</summary> ```json [ { "left": 4, "top": 4, "right": 1714, "bottom": 1400 }, { "left": 1722, "top": 4, "right": 1714, "bottom": 672 }, { "left": 1722, "top": 680, "right": 855, "bottom": 724 }, { "left": 2581, "top": 680, "right": 855, "bottom": 724 } ] ``` </details> ## Second Command <details> <summary>Broken</summary> ```json { "left": 4, "top": 4, "right": 1714, "bottom": 1400 } { "left": 1722, "top": 4, "right": 1714, "bottom": 672 } { "left": 1722, "top": 680, "right": 855, "bottom": 724 } { "left": 2581, "top": 255, "right": 854, "bottom": 1149 } ``` </details> <details> <summary>Good</summary> ```json { "left": 4, "top": 4, "right": 1714, "bottom": 1400 } { "left": 1722, "top": 4, "right": 1714, "bottom": 672 } { "left": 1722, "top": 680, "right": 855, "bottom": 724 } { "left": 2581, "top": 680, "right": 855, "bottom": 724 } ``` </details>

adam commented

@LGUG2Z commented on GitHub (May 22, 2024):

Looking at the output of the first command you can see that for both broken/good the top values on the last two rects are set to 680; this is the top position that the layout algorithm calculated and the position that was sent to the Windows API by komorebi.

However as the second command shows, something happened after komorebi sent the SetWindowPos call to the operating system and either the OS or the application itself did something before the final layout which led to the top position being adjusted to 255.

Unfortunately whatever happens after komorebi sends the API calls to Windows is a black box and there isn't really a way for us to know why the position given to SetWindowPos was not respected.

@LGUG2Z commented on GitHub (May 22, 2024): Looking at the output of the first command you can see that for both broken/good the `top` values on the last two rects are set to `680`; this is the top position that the layout algorithm calculated and the position that was sent to the Windows API by komorebi. However as the second command shows, something happened after komorebi sent the [`SetWindowPos`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowpos) call to the operating system and either the OS or the application itself did something before the final layout which led to the `top` position being adjusted to `255`. Unfortunately whatever happens after komorebi sends the API calls to Windows is a black box and there isn't really a way for us to know why the position given to `SetWindowPos` was not respected.

adam commented

@LGUG2Z commented on GitHub (May 22, 2024):

I'm curious as both of you tested with the primary monitor scaled higher, can you repro if your primary monitor is 100% and the secondary is 125%?

Also just tried this but still wasn't able to repro :/

@LGUG2Z commented on GitHub (May 22, 2024): > I'm curious as both of you tested with the primary monitor scaled higher, can you repro if your primary monitor is 100% and the secondary is 125%? Also just tried this but still wasn't able to repro :/

adam commented

@Insprill commented on GitHub (May 22, 2024):

The weird thing is that, if I'm correct, ~~only applications made with QT do this~~, and they only do it when in a tile bordering a monitor with a different scale. I don't know what the Python installer or Motu's driver software is made with, but I know Audacity is QT, and it'd make sense for the others to be QT as well. I'm not aware of any other QT applications for Windows that I can test to see if it's truly QT-related. Edit: It's not QT related.

Do either of you have an AMD GPU? I don't have an Nvidia card to test on currently, but I'm also wondering if it could be related to that 🤔

@Insprill commented on GitHub (May 22, 2024): The weird thing is that, if I'm correct, ~~only applications made with QT do this~~, and they only do it when in a tile bordering a monitor with a different scale. ~~I don't know what the Python installer or Motu's driver software is made with, but I know Audacity is QT, and it'd make sense for the others to be QT as well. I'm not aware of any other QT applications for Windows that I can test to see if it's truly QT-related.~~ Edit: It's not QT related. Do either of you have an AMD GPU? I don't have an Nvidia card to test on currently, but I'm also wondering if it could be related to that 🤔

adam commented

@LGUG2Z commented on GitHub (May 22, 2024):

Anything is possible 😅 For what it's worth all my tests were with an Nvidia GPU.

@LGUG2Z commented on GitHub (May 22, 2024): Anything is possible 😅 For what it's worth all my tests were with an Nvidia GPU.

adam commented

@CtByte commented on GitHub (May 22, 2024):

I also have an Nvidia GPU and you are right, this seems to be a deeply rooted issue somewhere that is not easy to reproduce.

It would be worth for someone to attempt this on an AMD machine with 2 monitors.

@CtByte commented on GitHub (May 22, 2024): I also have an Nvidia GPU and you are right, this seems to be a deeply rooted issue somewhere that is not easy to reproduce. It would be worth for someone to attempt this on an AMD machine with 2 monitors.

adam commented

@CtByte commented on GitHub (Jun 12, 2024):

@Insprill A lot has changed since, do you still have this issue or know more about it?

@CtByte commented on GitHub (Jun 12, 2024): @Insprill A lot has changed since, do you still have this issue or know more about it?

adam commented

@Insprill commented on GitHub (Jun 12, 2024):

I actually haven't updated komorebi since my last report. I'll update it tomorrow and report back. Hopefully it is since I have an ever-growing list of applications that need a tiny terminal open to use 😅

@Insprill commented on GitHub (Jun 12, 2024): I actually haven't updated komorebi since my last report. I'll update it tomorrow and report back. Hopefully it is since I have an ever-growing list of applications that need a tiny terminal open to use 😅

adam commented

@CtByte commented on GitHub (Jun 12, 2024):

I am not sure what you used before to make your windows transparent, but now komorebi has that added as well. Thought you might want to know so perhaps you can get rid of one app with a tiny terminal 😄

  "transparency": true,
  "transparency_alpha": 220,

@CtByte commented on GitHub (Jun 12, 2024): I am not sure what you used before to make your windows transparent, but now komorebi has that added as well. Thought you might want to know so perhaps you can get rid of one app with a tiny terminal 😄 ```json "transparency": true, "transparency_alpha": 220, ```

adam commented

@Insprill commented on GitHub (Jun 13, 2024):

I just updated komorebi to c022438a37 and the issue is unfortunately still present :/

I've been using Alacritty's opacity option to make it transparent, but having transparency in komorebi would be amazing, one step closer to matching my Hyprland config :P
I'll play around with it later.

@Insprill commented on GitHub (Jun 13, 2024): I just updated komorebi to c022438a37c811d5aa188386987bea4a88bc2833 and the issue is unfortunately still present :/ I've been using Alacritty's opacity option to make it transparent, but having transparency in komorebi would be amazing, one step closer to matching my Hyprland config :P I'll play around with it later.

adam commented

@CtByte commented on GitHub (Jun 13, 2024):

Well, thank you for checking it anyway.

When the komorebi bar is added eventually, I do have a few ideas inspired by Hyprland that I am planning on working on 😉

@CtByte commented on GitHub (Jun 13, 2024): Well, thank you for checking it anyway. When the komorebi bar is added eventually, I do have a few ideas inspired by Hyprland that I am planning on working on 😉

adam commented

https://github.com/LGUG2Z/komorebi/assets/165908630/d1414b68-97b3-4722-8ba2-81480926ec95

@CtByte commented on GitHub (Jun 13, 2024):

I have something, I am on c022438a37 and look at this "audacity".

I am using shortcuts to move Audacity around, but as soon as I move any other window on the screen, Audacity disappears and I can only bring it back by "moving" the borders (I can minimize and restore the window as well to bring it back).

Edit: This was on my "right" monitor. When I do the same on the "left" monitor, I can see that Audacity is "moved" to the "right" monitor.

@CtByte commented on GitHub (Jun 13, 2024): I have something, I am on c022438a37c811d5aa188386987bea4a88bc2833 and look at this "audacity". https://github.com/LGUG2Z/komorebi/assets/165908630/d1414b68-97b3-4722-8ba2-81480926ec95 I am using shortcuts to move Audacity around, but as soon as I move any other window on the screen, Audacity disappears and I can only bring it back by "moving" the borders (I can minimize and restore the window as well to bring it back). Edit: This was on my "right" monitor. When I do the same on the "left" monitor, I can see that Audacity is "moved" to the "right" monitor.

adam commented

@Insprill commented on GitHub (Jun 14, 2024):

Changing any setting that increases the distance of windows from the edges of the display fixes this problem (e.g. border_offset, default_workspace_padding, etc). I used to use a default_workspace_padding of 2, but 5 and above fixes the issue for me.

@Insprill commented on GitHub (Jun 14, 2024): Changing any setting that increases the distance of windows from the edges of the display fixes this problem (e.g. `border_offset`, `default_workspace_padding`, etc). I used to use a `default_workspace_padding` of `2`, but `5` and above fixes the issue for me.

adam commented

@CtByte commented on GitHub (Jun 14, 2024):

These are my settings that are related to spacing and sizes. The video still valid for me and Audacity jumps around the screen.

  "default_workspace_padding": 10,
  "default_container_padding": 10,
  "border_padding": 5,
  "border_width": 3,
  "border_offset": -1,
  "stackbar": {
    "height": 40,
    "label": "Title",
    "mode": "OnStack",
    "tabs": {
      "width": 300,
      "focused_text": "#bfaa69",
      "unfocused_text": "#dfe2f3",
      "background": "#121826"
    }
  },
  "global_work_area_offset":
  {
    "bottom": 45,
    "left": 0,
    "right": 0,
    "top": 45
  },

if you were referring to your original issue, then that is a step forward, I think.

perhaps Audacity should just be floated 😄

@CtByte commented on GitHub (Jun 14, 2024): These are my settings that are related to spacing and sizes. The video still valid for me and Audacity jumps around the screen. ```json "default_workspace_padding": 10, "default_container_padding": 10, "border_padding": 5, "border_width": 3, "border_offset": -1, "stackbar": { "height": 40, "label": "Title", "mode": "OnStack", "tabs": { "width": 300, "focused_text": "#bfaa69", "unfocused_text": "#dfe2f3", "background": "#121826" } }, "global_work_area_offset": { "bottom": 45, "left": 0, "right": 0, "top": 45 }, ``` if you were referring to your original issue, then that is a step forward, I think. perhaps Audacity should just be floated 😄

adam commented

@Insprill commented on GitHub (Jun 14, 2024):

Yes, I was referring to my issue; I'm unsure if yours relates to this. Audacity isn't the only program that this happens to me with; there are several others (GIMP, Python installer, MOTU drivers, probably a couple of others I'm forgetting), most of which I would like to be tiled - that is the reason I'm using komorebi after all :P

Increasing default_workspace_padding seems to be reliable for me. All of the aforementioned applications are fine with it at 5. It's definitely a step forward; if it can't be fixed, it can at least be noted in the docs for others who may come across the same issue, but I would still like it to be fixed as I prefer having tiny edge gaps.

@Insprill commented on GitHub (Jun 14, 2024): Yes, I was referring to my issue; I'm unsure if yours relates to this. Audacity isn't the only program that this happens to me with; there are several others (GIMP, Python installer, MOTU drivers, probably a couple of others I'm forgetting), most of which I would like to be tiled - that is the reason I'm using komorebi after all :P Increasing `default_workspace_padding` seems to be reliable for me. All of the aforementioned applications are fine with it at `5`. It's definitely a step forward; if it can't be fixed, it can at least be noted in the docs for others who may come across the same issue, but I would still like it to be fixed as I prefer having tiny edge gaps.

adam commented

@CtByte commented on GitHub (Jun 14, 2024):

Then I think we should keep focus on your issue for now, a solution to that might just fix mine as well.

@CtByte commented on GitHub (Jun 14, 2024): Then I think we should keep focus on your issue for now, a solution to that might just fix mine as well.

adam commented

@agent-kilo commented on GitHub (Aug 21, 2024):

I had this exact same issue while writing my own window manager, did some tests, and found out these prerequisites to trigger it (on Windows 10 Build 19045 at least):

Have at least 2 monitors with different DPI placed side-by-side;
The triggering application window must be DPI-unaware;
That very DPI-unaware window has at least one row/column of pixels shown on a monitor that has a different DPI value, and this includes the invisible borders added by the Windows shell (the invisible non-client area).

For example, we have 2 monitors arranged horizontally, each with a resolution of 1920x1080, but the left one has 96 DPI, and the right 192. For a window of width 100, displayed on the left monitor, it has 7 pixels of invisible border on the left and right sides. Trying to place it further right from the x coordinate 1806 would trigger this issue.

I couldn't find a proper solution either. It seems there are only two ways to go as a user:

Make the windows, including their invisible borders, stay away from monitor edges. This means there will be gaps of at least 7 pixels around the monitors, and those gaps scale with DPI settings - higher the DPI, larger the gap. Or,
Make sure all the monitors have the same DPI setting.

Hopefully the situation would improve over time, as the applications & GUI tool kits are adding high DPI support.

@agent-kilo commented on GitHub (Aug 21, 2024): I had this exact same issue while writing my own window manager, did some tests, and found out these prerequisites to trigger it (on Windows 10 Build 19045 at least): 1. Have at least 2 monitors with different DPI placed side-by-side; 2. The triggering application window must be [DPI-unaware](https://learn.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows#dpi-unaware); 3. That very DPI-unaware window has at least one row/column of pixels shown on a monitor that has a different DPI value, and this includes the invisible borders added by the Windows shell (the invisible non-client area). For example, we have 2 monitors arranged horizontally, each with a resolution of 1920x1080, but the left one has 96 DPI, and the right 192. For a window of width 100, displayed on the left monitor, it has 7 pixels of invisible border on the left and right sides. Trying to place it further right from the x coordinate 1806 would trigger this issue. I couldn't find a proper solution either. It seems there are only two ways to go as a user: 1. Make the windows, including their **invisible borders**, stay away from monitor edges. This means there will be gaps of at least 7 pixels around the monitors, and those gaps scale with DPI settings - higher the DPI, larger the gap. Or, 2. Make sure all the monitors have the same DPI setting. Hopefully the situation would improve over time, as the applications & GUI tool kits are adding high DPI support.

adam commented