search

fuhsjr00 / bug.n

Tiling Window Manager for Windows
GNU General Public License v3.0
3.35k stars 212 forks source link

Applications on a secondary vertical monitor not fitting on the desktop properly #194

Open samwdp opened 5 years ago

samwdp commented 5 years ago

Windows Version: 10.0.17134 Build 17134 bug.n Version: 9.0.1

I will preface this with; I have only just downloaded this and started to use bug.n therefore the config is the same as the one provided. My problem is that I have a secondary monitor in a vertical alignment. When I move windows onto the vertical monitor, the application window extends past the screen. I am in the tile layout mode. I have tried nearly every configuration option; changing the layout axis, change the stack axis. It seems when I pres win ctrl tab nothing seems to happen on the secondary monitor so I am unable to determine if that is the issue. Something I have also observed, that is odd, regarding this is that when I change the gap spacing; I get a flicker effect seeing the window how I think it is supposed to be displayed, but it then goes back to the example picture provided.

Here is a screenshot of my secondary monitor. example

Any more information I will try to provide

joten commented 5 years ago

WinCtrlTab should rotate the master axis. From your screenshot I take it, that you have to windows in the master area, and below that you should have a horizontal stack. How many windows are on that monitor and view in total? You may try the layout on that monitor with a bunch of Explorer windows for testing purposes.

I can see two possibilities: (1) An compatibility issue with Visual Studio Code, where the window cannot be resized correctly. You may try maximizing the window and re-applying the layout. (2) A monitor scaling issue; that may be a bug in bug.n. You may try to use the current development version, which is fairly stable.

samwdp commented 5 years ago

I only had 1 window on that monitor. On my primary monitor vs code tiles like I would expect. I have put 6 explorer windows on my secondary monitor. Here is the output of win I: ID: 0x1d0fc0 class: CabinetWClass title: This PC process: explorer.exe [7172] style: 0x14CF0000 metrics: x: -1790, y: 184, width: 879, height: 1566 tags: 1

Config_rule=CabinetWClass;This PC;;1;2;1;0;1;0;

example2

I shall try the recent dev version :)

samwdp commented 5 years ago

I have tried using the latest dev release and I am still running into the same issue. It seems to be when I press win shift , to move the window to the next screen, the height and width of the window gets preserved from my main window and doesn't downsize to the secondary monitor. Then the windows gets shifted in some strange way so the 0,0 point is off the screen

samwdp commented 5 years ago

ID: 0x60122 class: Chrome_WidgetWin_1 title: Applications on a secondary vertical monitor not fitting on the desktop properly · Issue #194 · fuhsjr00/bug.n - Google Chrome process: chrome.exe [17980] style: 0x16CF0000 metrics: x: -2706, y: 157, width: 3525, height: 3549 tags: 256

Config_rule=Chrome_WidgetWin_1;Applications on a secondary vertical monitor not fitting on the desktop properly · Issue #194 · fuhsjr00/bug.n - Google Chrome;;1;2;256;0;1;0;

joten commented 5 years ago

Sadly, I have no idea, what's wrong. Currently, I do not have a second monitor at hand and can not reproduce the issue. It looks as if the monitor is recognized with wrong x-coordinate and width, but in the current version, bug.n does not log these values.

joten commented 5 years ago

I added some debugging information regarding the monitor configuration. If possible, please try the current development version and post the log entries for "Manager_init", "Monitor_init" and "Monitor_getWorkArea"; which Windows version/ build are you using?

joten commented 5 years ago

With commit https://github.com/fuhsjr00/bug.n/commit/413a7c19760eec6c511ab938cc9cf295847c881d to the X branch I added per-monitor display scaling awareness. I could only test in a single monitor system, but could reproduce the issues regaring a too wide bug.n status bar and layout at first, and the changes had at least a mitigating effect. Have a try, if you have time.

joten commented 5 years ago

With commit 0f9f537040bdca074feb52226050e3c680c3003c I also added the changes to the master branch; the X branch will get a bit more unstable.

If it is sufficiently tested, I will release it with version 9.1.0, therewith providing an executable.

ghost commented 5 years ago

The scaling doesn't seem to work for me. I tried version 9.1.0 and I have these monitors: Monitor1: on the right | 1920x1080 | 125% scaling Monitor2: on the left | 1900x1200 | 100% scaling Monitor3: in the middle | 2560x1440 | 125% scaling

But I get the following 2019-04-24 14:21:45 DEBUG[0] Monitor_getWorkArea: #1, l: 3200, r: 5120, t: 435, b: 1515. 2019-04-24 14:21:45 DEBUG[0] Monitor_getWorkArea: #2, l: -2400, r: 0, t: 145, b: 1645. 2019-04-24 14:21:45 DEBUG[0] Monitor_getWorkArea: #3, l: 0, r: 2560, t: 0, b: 1440.

This shows that the offset is not correctly calculated

joten commented 5 years ago

The per-monitor-scaling is currently only implemented in the development version. I have yet to make a new release including the latest change.

Although, I have to admit that the values do not seem to add up anyway. Can you test the development version (as an AutoHotkey script -- no bug.n executable available)?

ghost commented 5 years ago

Hi, sorry I am no longer able to test it on my work machine. So I can't support on this sadly.