Running bug.n puts all windows small in top left, unusable

[JohnCHarrington]

I am running a new install of Windows 10.

When I run bug.n I just get the screenshotted behaviour. I cannot tile windows at all, they are always either tiny or maximised unless resized by the mouse.

Other shortcuts seem to work, but the windows can only be moved by the mouse, not with any shortcuts, and they do not properly tile.

[joten]

This looks as if the monitor dimensions are not recognized, resulting in zero values with all windows moved to the top left corner and resized to their minimal width and height. Does restarting bug.n has any effect?

Sadly, there is no debugging information, which bug.n provides for this case, and I am currently not running Windows on my machine. Nevertheless, I added two lines of code via the web interface, which should result in additional log entries while starting bug.n. If possible, please have a try with the current development version and post the log entries for "Manager_inti" and "Monitor_init".

-- I hope, there is no compatibility issue with Windows 10 1809.

[JohnCHarrington]

That appears to be the case, probably because I am running windows on a MacBook Pro with a retina display. Here are the new log entries:

2019-01-17 16:06:24 DEBUG[0] Manager_init: Found 1 monitors.
2019-01-17 16:06:24 DEBUG[0] Monitor_init: #1, name: \\.\DISPLAY2, x: 0, y: 12, w: , h: .

Is there anyway I can force it to recognise this monitor?

[joten]

That looks bad. The monitor is recognized, but something goes wrong calculating the width and height. I added some more debugging code with commit 125bcdd. If possible, please try the now current development version and post the log entries for "Manager_inti", "Monitor_init" and "Monitor_getWorkArea"; which Windows version/ build are you using?

[JohnCHarrington]

Did you change anything else? It actually did tile things this time. New output:

2019-01-17 21:38:58 DEBUG[0] Monitor_getWorkArea: #1, l: 0, r: 2560, t: 0, b: 1600.
2019-01-17 21:38:58 DEBUG[0] Monitor_init: #1, name: \\.\DISPLAY1, x: 0, y: 24, w: , h: .
2019-01-17 21:38:58 DEBUG[0] Monitor_getWorkArea: #1, l: 0, r: 2560, t: 0, b: 1600.

Windows 10, Version 1809, Build 17763.253

[Kukunin]

I run bug.n on the same Windows 10, Version 1809, Build 17763.253 and it works fine. It seems like an issue with the Macbook's display

[joten]

On the one hand it is good to see, that it is not a compatibility issue with Windows 10, Version 1809, on the other hand I am at a loss with this issue.

I just added debugging lines, nothing else, which may point in the direction of a strange timing problem; but that is just guessing. The latest output though looks a bit odd:

• First it was "\.\DISPLAY2", now it is "\.\DISPLAY1"; did you change your monitor configuration, any external display?
• You have two "Monitor_getWorkArea" lines in the latest output (should only be one for each monitor, recognized), but no "Manager_init: Found 1 monitors."; is it all, as it was in the log file?

[JohnCHarrington]

This was the full output:

2019-01-17 21:38:58 ====== Initializing ======
2019-01-17 21:38:58 DEBUG[0] Monitor_getWorkArea: #1, l: 0, r: 2560, t: 0, b: 1600.
2019-01-17 21:38:58 DEBUG[0] Monitor_init: #1, name: \\.\DISPLAY1, x: 0, y: 24, w: , h: .
2019-01-17 21:38:58 DEBUG[0] Monitor_getWorkArea: #1, l: 0, r: 2560, t: 0, b: 1600.
2019-01-17 21:38:58 Window ahk_id 0x805e2 process '' doesn't match expected 'firefox.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x10616 process '' doesn't match expected 'WinStore.App.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x10021e process '' doesn't match expected 'ApplicationFrameHost.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x10534 process '' doesn't match expected 'SystemSettings.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x1051e process '' doesn't match expected 'ApplicationFrameHost.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x101fc process '' doesn't match expected 'Explorer.EXE', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x101e4 process 'SearchUI.exe' doesn't match expected 'Explorer.EXE', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x10162 process 'svchost.exe' doesn't match expected 'Explorer.EXE', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x304ae process '' doesn't match expected 'dragonbar.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x301d2 process '' doesn't match expected 'Explorer.EXE', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x20210 process '' doesn't match expected 'Explorer.EXE', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x202d4 process 'OneDrive.exe' doesn't match expected 'NordVPN.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x50940 process '' doesn't match expected 'mmc.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x40716 process '' doesn't match expected 'AutoHotkey.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x60600 process '' doesn't match expected 'quickassist.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x8073a process '' doesn't match expected 'quickassist.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x109ba process '' doesn't match expected 'quickassist.exe', forgetting this window
2019-01-17 21:38:58 Window ahk_id 0x309da process '' doesn't match expected 'quickassist.exe', forgetting this window
2019-01-17 21:38:58 ====== Running ======
2019-01-17 21:39:47 ====== Cleaning up ======
2019-01-17 21:39:48 DEBUG[0] Monitor_getWorkArea: #1, l: 0, r: 2560, t: 0, b: 1600.
2019-01-17 21:39:48 ====== Exiting bug.n ======

The DISPLAY1/DISPLAY2 issue could be something to do with the fact that I probably did plug into an external monitor between tests, however there was only ever the single laptop built in display when I ran these tests.

[joten]

It is propably an issue that the whole initialization is done in a single second; bug.n was intially developed on a netbook a decade ago, which was far less powerfull than a MacBook nowadays.

I added Config_shellMsgDelay (via the web interface, not tested) to defer the monitor initialization a bit, by default 350 ms; you may try different values by setting the variable in Config.ini.