Unexpected monitor/window focus change in multi-monitor environment

[KristofferC]

Underlying problem:

There is a conflict between the two active window managers:

• Windows tries to activate the previously active window according to its own stack, if the active window is closed, or the user wants to activate a window by mouse.
• bug.n tries to maintain the currently active monitor.

  Case 3 (submitted by fuhsjr00):

  Current behavior:

Sometimes switching a view from an empty view to a non-empty view causes a monitor switch. This one can't be reproduced as reliably as the previous case.

1. Setup monitor 2 with at least one empty view and one non-empty view.
2. Setup monitor 1 with a non-empty view.
3. Make the non-empty view active on monitor 1 and the empty view active on monitor 2.
4. Make monitor 2 the active monitor.
5. Switch to monitor 1 with the #, hotkey
6. Cycle through some of the windows on monitor 1 with #Up and #Down. I can't recommend a specific pattern.
7. Switch to monitor 2 with the #. hotkey
8. Switch to the non-empty view with the corresponding hotkey.

Observe: Sometimes the active monitor will switch back to monitor 1.

Expected behavior:

The active monitor should not change, and the window activated should be the active window for the non-empty view on monitor 2.

---

DONE

Case 1 (submitted by KristofferC):

Current behavior:

1. Have a windows on monitor 1 as active window.
2. Move cursor to a window on monitor 2 and click on it.

Observe: Focus will now instantly switch back to the "master" window on monitor 1.

This makes it impossible to work on another monitor without using the Hotkey for Manager_activateMonitor(1) and Manager_activateMonitor(2) everytime you want to change between monitors.

Expected behavior:

It would be more comfortable if I just got the window I clicked on on the other monitor as active.

Case 2 (submitted by fuhsjr00):

Current behavior:

1. Click on window on monitor 1.
2. Click on window on monitor 2 and close it via "#c".

Observe: Monitor focus changes back to monitor 1. This happens regardless of whether the closed window was the last window in the view.

Expected behavior:

I think that the behavior should be to stay on the empty view on that monitor until the user explicitly changes monitor or view.

---

Remainder of the original post:

Hello,

I am not sure this is the right place to write stuff but I didn't find a better one.

I don't know if the following is intended behavior or not but it feels weird so I mention it.

[bug report, see above]

Another question: Is it possible to make bug.n automatically focus windows on mouseover (like xmonad does for example).

I didn't find anything about this in the documentation but I might have missed something.

Thanks for this program, it makes Windows bearable to work on.

[DunkelKolar]

I have the same problem here :).

[joten]

Another question: Is it possible to make bug.n automatically focus windows on mouseover (like xmonad does for example).

bug.n itself does not provide this functionality, because Windows already does: Start > Control Panel > Ease of Access > Ease of Access Center > Make the mouse easier to use > check Activate a window by hovering over it with the mouse option

bug.n provides the functionality the other way around:

Config_mouseFollowsFocus=1

If true (=1), the mouse pointer is set over the focused window, if a window is activated by bug.n.

[joten]

BTW, "this is the right [and only] place to write stuff" -- at least regarding bug.n.

This issue seems to be related to issue #6; therefor I will consolidate those two in an attempt to clarify the expected behavior under the different circumstances; I will edit the top post.

[joten]

I merged this issue with issue #6.

[joten]

Case 1

• At last it is not a regression bug, although it is related. The previous fix only changed the behavior when closing windows with bug.n (#c).
• Three variants:
  • Only allow changing the active monitor including the active window by bug.n-hotkeys (current behavior). -- Obviously not.
  • If activating a window by any means, also change the active monitor accordingly. -- Preferable.
  • Allow a mix-up, keeping the active monitor, but changing the active window, even if it is on another monitor. -- Might be confusing.

Case 2

• Two variants, when closing the currently active window:
  • Activate the previously active window (according to the workflow?) where ever it resides, resetting the active monitor.
  • Activate the 'next' window on the monitor, where the closed window resided. -- Preferable.

The problem

The shell message when closing a window is not distinct; sometimes bug.n only recognizes the closing only because Windows activates another window. -- And there you have it: case 1 and 2 may be triggered by the same event, but require different actions.

I will explore the possibility, if the events can be distinguished.

Any comments on the choices made in case 1 (variant 2) and case 2 (variant 2) (@KristofferC and @fuhsjr00 )?

[joten]

I tested. -- I overdone it a bit.

Version	Case 1	Case 2	Case 3
bug.n 8.3.0	x	-	-
bug.n-dev.exe	-	(x)	-
current Main.ahk	-	-	-

x: reproduced, (x): reproduced in some way, -: not reproducable

Therefor ... @KristofferC & @DunkelKolar: Are you using version 8.3.0 (the current stable version)? If so, you may want to use the current development version; the next release (8.4.0) may still take some time.

@fuhsjr00: I extended your fix in Manager_closeWindow() by adding it to Manager_unmanage(). But I still had no luck, reproducing case 3.

Is this issue solved for cases 1 and 2?

[joten]

As far as I can see, cases 1 and 2 are solved and case 3 cannot be reproduced consistently.

I edited the top post reflecting this status and removed the "bug" label.

[rajaiyer]

First of all. Thanks for developing this code. This is absolutely helpful. Makes my life easy as I navigate between windows using just keys.

I have been having a similar issue and am not sure how to navigate this issue. My current configuration includes 2 external monitors . The main issue I have is that sometimes I am absolutely unable to access one of the monitors (leftmost). I am rather naive to the coding behind it. There are 9 tags on each (including this) monitor. Usually I will have windows open to occupy 2-3 tags on each monitor. However if I try to access access tag-4 ("#1", "#2", "#3", "#4") on the leftmost monitor it automatically goes to the middle screen. There is not a consistent pattern I notice. However it happens often enough to cause problems.

Any suggestions on how to overcome it ?

Thanks Raja

[qwelyt]

I think I might have the same, or at least a similar problem, as @rajaiyer. I have two monitors, A and B, where A is the main-monitor (with the start button). If I use #, to change from A to B, and then try to change workspace with #2, the workspace on monitor A is changed instead of on B. From what I can tell, it seems to happen if monitor Bs currently active workspace is empty, regardless if monitor A has anything on its workspace or not (i.e, if(B.currentWorkspace == empty){ use A.currentWorkspace}). Which is quite annoying as it becomes quite hard to actually switch back to a workspace that is not empty on monitor B.

[qwelyt]

I would also add that clicking on the number results in odd behaviour. Eg: Monitor B has an empty workspace active, but monitor A has non-empty workspace active. Click 1 on monitor B (actually use the mouse and click on the number), the workspace on monitor A changes. This can take about 1-5 times before succeeding to switch workspace on monitor B.

[x29a]

The commit introduced focusing issues on my Windows 7, dual monitor setup. Reverting the changes removed the regression.

I am working with VisualStudio with the "Output" window on the second monitor. Lets say i have VisualStudio on view 4 and switch to view 1. I can still see the Output window on monitor 2 and interact with it, especially open context menues in it.

No when i switch to view 4, i can not select anything within the Output window anymore since it immediately changes the focus to the whole window instead of the content in it (i see a border around it).

My monitor views are synced, so i always switch both of them at the same time.

I attached a debug log, not sure if it helps. focus_log.txt

[joten]

Unfortunately, I am not using VisualStudio and cannot reproduce the issue.

I could not get enough information from the log you provided to determine the problem. The question arises, which of the windows you mentioned have which IDs.

Can you provide me with a log.txt and a corresponding data\_WindowState.ini?

[nileshp87]

There's an issue which exists for me, perhaps others can confirm with 2 monitors.

To reproduce:

1. Pull up two applications, one per monitor.
2. Switch to a desktop with nothing on it on either of the two monitors.
3. Try and switch back to the old desktop will only cause the monitor with an active window to change. There is no way to give focus back to the old monitor for hotkeys besides manually clicking in the status bar.

[x29a]

@nileshp87 What version of bug.n are you using and which windows? I tried reproducing your problem, and it works for me. Is it happening with specific applications for you? How are you switching between desktops? Can you append your config?

[nileshp87]

When I posted that I was on latest release, but switching to dev seems to have resolved the problem. I was noticing some weirdness still, but I can't seem to find the exact method to consistently reproduce.