fuhsjr00 / bug.n

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

Sometimes taskbar cannot be disabled, but only on one monitor #192

Open dav1d-wright opened 5 years ago

dav1d-wright commented 5 years ago

I have three monitors, sometimes after a while it happens that on one of the monitors the Windows taskbar cannot be disabled.

joten commented 5 years ago

Can you describe the issue in more detail, what do you mean by "cannot be disabled"? E.g. can you still activate normal windows? What about the start menu, i.a. when not activating it by click, but by Windows-hotkey?

dav1d-wright commented 5 years ago

@joten the windows start menu functions normally when calling it using the windows hotkey, however the taskbar cannot be hidden using win+spacebar. In the meantime there was also the issue where the taskbar is hidden but cannot be shown using the win+spacebar hotkey.

joten commented 5 years ago

Hm, sounds like a compatibility issue, since it shows up a bit irregular. Do you run bug.n as administrator? And do othe hotkeys work in this situation, when WinSpace does not work? One possibillty might be, that an application with elevated privilegues is active, therefor bug.n does not receive the keyboard event.

dav1d-wright commented 5 years ago

This problem is very difficult to reproduce, but I think it might be caused by changes in the monitor configuration. It happens sometimes when I dock or undock my laptop, although resetting the monitor configuration does not help. I also tried to remove the configuration file, but that didn't change anything regarding the monitors.

I found out that sometimes when this occurs, I can show/hide the task bar when I first hide the title bar. And another thing that sometimes occurs when I do that is that simultaneously the taskbar of another screen hides when I try to show the taskbar of this screen.

One more thing that started happening when this problem occurs is that one of the screens (I have two monitors and the laptop screen open) is that one of the windows does not accept any windows moved to it. I see that this Window has a weird layout icon that I cannot change to the icon 1x1|=. Is there maybe some layout set incorrectly? I removed the _Layout.ini file to have it reset but that didn't fix it.

I would appreciate your help with this.

image

dav1d-wright commented 5 years ago

Okay this is a bit embarrassing. After hours trying to fix this and modifying the Config file I found the resolution minutes after posting this. I removed the _Layout.ini file before closing or resetting bug.n, and when I closed bug.n again I saw that the files are being recreated when bug.n is closed. I deleted the layout file again and restarted, this fixed the issue.

What I do not understand is what caused it, i.e. what I have to change in the layout file when it occurs again.

joten commented 5 years ago

Toggling the Taskbar depends on the active monitor, which is determined by the active window. First toggling a window title bar may help, since the active window is reset and therewith the active monitor. This may explain some of the behaviour you descibed.

The monitor with no windows from your screenshot, seems to be monitor 3 with a Google Chrome window associated to it, which really seems to be located on monitor 1 in the top left corner with minimal width and height. This indicates that something was messed up regarding monitor 3 dimensions. Sadly, bug.n currently does not log those settings.

_Layout.ini saves the the current layout settings (Config.ahk, line 365 ff); you may post the contents of _Layout.ini, perhaps it gives us a clue to what went wrong.

You may set Config_autoSaveSession=off to prevent bug.n from using _Layout.ini.

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?

dav1d-wright commented 5 years ago

I am terribly sorry for only answering so late, it seems that I haven't received any e-mails for the messages you wrote. I will try to run the current development version right now. I am using Windows 10 Version 1703 OS Build 15063.1563)

dav1d-wright commented 5 years ago

When I try to run the latest development version by double-clicking Main.ahk , my computer starts lagging, and it seems to be stuck in initialization. I am attaching a screenshot and the log file.

If I choose "open with" for Main.ahk and select AutoHotKey it says that there is an error on line 185: #Include file "Bar.ahk" cannot be opened.

Is it anything that I'm doing wrong?

I'm running AHK Version 1.1.30.01

untitled log.txt

joten commented 5 years ago

I never encountered the first issue. You may try closing all other applications (i.a. Outlook) and retry starting bug.n. Are you running AutoHotkey with the 32-bit, unicode version?

Regarding the second issue, bug.n Main.ahk has to be started with the src directory as the working directory. But it looks as if you have associated .ahk files with the AutoHotkey.exe, therefor it should not be necessary to start it differently.