Style PositionPlacement ignores y percentage #265
Comments
|
Hi @afhp-2020 Oh, good. Looks like I've trampled over some previous value when shoe-horning in RandR. Don't suppose you're up for submitting a patch to fix this, are you? :) Have a look at |
|
I'll give it a look, but no promises :) I'm not that much of a C developer. While I'm at it I should also give #40 a shot... |
Heh, thanks! You don't need to be a C developer, just someone who has more of a brain than I do... ;) As for #40 -- go for it! I think I recall starting a pull-request to move things along with that, but since I'm generally ambivalent with how iconic windows appear on different monitors for me, I've not really focused on revisiting my fix for that. Selfish programming, eh? :) |
|
Version |
|
Hi @afhp-2020 Are you saying this is fixed? |
|
Hi Thomas, It is not fixed: things worked in a previous, 1.0.0 - level version, and are broken as of 1.0.1. More specifically, bisecting for #264, it broke on (both issues appear simultaneously) |
When computing and setting the EWMH work area (which also implies EwmhBaseStrut settings), calculate the struts relative to the overall screen widths and heights. Certain monitors with certain resolutions combined will often have "dead space" which calculating per-monitor is a distorted value. The window's offset against the work area is calculated when placing/maimizing a window, so doesn't incur per-monitor offsets. Fixes #271, fixes #265, fixes #264, fixes #250
When computing and setting the EWMH work area (which also implies EwmhBaseStrut settings), calculate the struts relative to the overall screen widths and heights. Certain monitors with certain resolutions combined will often have "dead space" which calculating per-monitor is a distorted value. The window's offset against the work area is calculated when placing/maimizing a window, so doesn't incur per-monitor offsets. Fixes #271, fixes #265, fixes #264, fixes #250
When computing and setting the EWMH work area (which also implies EwmhBaseStrut settings), calculate the struts relative to the overall screen widths and heights. Certain monitors with certain resolutions combined will often have "dead space" which calculating per-monitor is a distorted value. The window's offset against the work area is calculated when placing/maimizing a window, so doesn't incur per-monitor offsets. Fixes #271, fixes #265, fixes #264, fixes #250
When computing and setting the EWMH work area (which also implies EwmhBaseStrut settings), calculate the struts relative to the overall screen widths and heights. Certain monitors with certain resolutions combined will often have "dead space" which calculating per-monitor is a distorted value. The window's offset against the work area is calculated when placing/maimizing a window, so doesn't incur per-monitor offsets. Fixes #271, fixes #265, fixes #264, fixes #250
Given the configuration line defined previously
the script window is expected to appear at the left of the screen (taking struts into account), 3/4 of the way down as it did previously. Instead, it appears at the top of the screen.
Changing the line (through FvwmConsole) to
makes it appear where expected.
Modifying the x component (as a percentage, without suffix) behaves as expected.
version 1.0.1 (1.0.0-45-gb1072488)
The text was updated successfully, but these errors were encountered: