-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected monitor/window focus change in multi-monitor environment #14
Comments
I have the same problem here :). |
bug.n itself does not provide this functionality, because Windows already does: bug.n provides the functionality the other way around:
|
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. |
I merged this issue with issue #6. |
Case 1
Case 2
The problemThe 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 )? |
I tested. -- I overdone it a bit.
Therefor ... @fuhsjr00: I extended your fix in Is this issue solved for cases 1 and 2? |
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. |
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 |
I think I might have the same, or at least a similar problem, as @rajaiyer. |
I would also add that clicking on the number results in odd behaviour. |
+ revised Manager_getWindowInfo regarding hidden windows
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. |
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 |
There's an issue which exists for me, perhaps others can confirm with 2 monitors. To reproduce:
|
@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? |
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. |
Underlying problem:
There is a conflict between the two active window managers:
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.
#,
hotkey#Up
and#Down
. I can't recommend a specific pattern.#.
hotkeyObserve: 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:
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:
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.
The text was updated successfully, but these errors were encountered: