-
-
Notifications
You must be signed in to change notification settings - Fork 58
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
Problematic focus shift in dual monitor setup #141
Comments
Thanks for the report. I noticed this behavior, too, but never thought that it might be caused by this extension. In fact, what I found is that this behavior is likely the same than that of the vanilla workspaces and only appears different. Here is what you can try to test this:
My guess why the app on the other monitor is focussed here is that by switching from the top right workspace to the bottom right, GNOME "virtually" passes over the bottom left workspace (as if they were still linear) and by doing so, focusses the app on the other monitor because the bottom left workspace is empty. You can confirm this by disabling this extension. Here you should end up with four linear workspaces where the first two and the last contain apps. If you switch from the first to the last, the app on the other monitor is focussed once you pass over the empty workspace, and stays focussed. I'm not sure if this behavior can be changed/fixed by this extension. But I agree that it probably would make sense. Maybe even the default behavior can be considered faulty and this can be fixed in upstream GNOME. |
Thanks for getting back to me. Clearly, you have a much deeper understanding of how workspaces work than me :-) I ran the tests that you suggested:
Unfortunately, I don't get consistent behaviour for the test case with disabled extension:
However, I should say that my knowledge about this is rudimentary at best. E.g. it could well be that it's not the type of the app that influences the behaviour but the point in time when the app on the other screen has been opened. (pdf viewer has been open for hours, firefox just for this test). Or maybe there's an internal queue of when apps were last focussed (this might make sense for cycling through apps with alt+tab)? Another observation: |
Not really, I can only find things out by trial and error. There is no documentation for these kinds of things (or the entire GNOME JavaScript API for that matter) that I'm aware of. You seem to be correct. The focussed window seems to be determined by some sort of queue of windows that were focussed last. If the window on the other monitor has been focussed (manually) more recently than any window on any workspace, it will get focus if switched to that workspace. If the workspace is empty, the window on the other monitor will get focus but won't change position in the queue. Can you confirm this? This seems to be at least some sort of consistent behavior. |
Yes, I think you are right. There seems to be a queue involved, and returning or keeping focus from the other screen is determined by the position of the other screen's application in the queue. However, I just spent 30min or so trying to get consistent results with different approaches but failed. I leave the table I started in this post, but I think the takeaway is that there are other factors contributing to the focus selection that we haven't understood. Let me know if there's anything I can to help with that, but for now, am I right in assuming there's no easy fix fo this? Here is my setup, when changes workspaces from top left to top right on a 3x3 matrix:
|
That's right. By now, I suspect that this behavior is not caused (or to be fixed) by this extension. You could ask in the GNOME repo what the expected behavior should be and/or propose an improvement. |
I've posted a question on gnome discourse: Hope someone is able to point me to the right direction. |
I think I should have noticed this long time ago, I never get the windows queue shuffled. I don't think that there is anything in |
I use Xorg. Does your setup have workspaces on all monitors or only on one and the other two are single workspaces? I have a main monitor with workspaces and a second monitor with a single workspace. I believe the primary issue is that I expect the windows of the main monitor to be focused but the window on the second monitor gets focus when I switch workspaces. |
All of my monitors have workspaces enabled. so I don't use a single workspace on some monitors. |
Thanks for your responses - it's a tricky problem to describe. A one-sentence summary of the core problem:
This is super annoying as it requires manually refocussing the application on the target workspace. I've posted a question on My gut feel is this a I've made my peace with it - happy for this issue to be closed :-) |
Thanks @jangroth, I too think this will be very annoying, but for some reason I have never experienced this issue before. |
@ebeem - it could be a simple as this:
This might explain the difference. My setup uses workspaces on one monitor only (so that I can keep important apps like Slack on the other), and the interfering application always sits on that static workspace. I assume this will run through different code paths when shifting focus for me than for you. |
That was my thought as well, we have a different setup. IIRC in my last test GNOME did behave consistently but not always as I would expect. It puts the focus on the most recently focused window (for each workspace, no matter what monitor). I would expect that it puts the focus on the most recently focused window on my main monitor. For me this issue is about the cases where the (consistent) behavior does not match my expectations. |
Alright, now I understand, I thought since this happens only on single workspaces then it might be the case. I gave it a quick test and it turned out that the behavior is actually consistent somehow if you know how So in my case when I have workspaces span monitors I don't face this issue, the reason behind that is because every time I change my workspace, my entire Now in your case, when you change your workspace only in one single monitor, your
1- I am playing some music using what happened in |
Going with your example, I experience the problem in a slightly more complex setup:
Shifting workspaces from At least not always. I've spent hours trying to find a system behind the unwanted behaviour, but couldn't get to the bottom of it. Hence my question on Gnome Discourse to understand the expected behaviour, but no response. I guess it's a difficult setup that's hard to explain. |
I am not sure if I explained it well or not, but hovering shouldn't give focus to a window. Maybe try changing the workspaces without playing with the focus, just change workspace and see which window is being focused. If you are not getting consistent results then there is a problem. About the focus that happened to setup
scenario: So if you jump immediately to |
I think there might be some source of confusion in the word hovering. To get from
In other words: There's no way for me to get from OTH, let's not take it too far here. I have since learned that this is quite a specific problem that you would only experience in a dual-monitor/single-workspace setup. I believe the problem is most likely caused upstream and feel I did the right thing by trying to initialise a discussion on Gnome Discourse. I'm happy to call it quits :-) Thanks everyone for their help and input! |
@jangroth sorry, didn't notice you had some queries in here. gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-3 "['<Control><Alt>KP_3']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-3 "['<Control><shift><Alt>KP_3']" However, I don't think that this will be resolved as there's no way to predict the expected behavior of the user for this problem. |
First of all, I'd like to thank you for implementing this extension. It's one of my most important plugins and I have organized my complete work setup around having workspaces in a matrix! 💚
I'd like to report a problem that only occurs in dual-monitor setup:
Setup:
Action:
Expectation:
Problem:
Or, in simpler words: When switching between two apps on different workspaces, the focus gets transferred to an unrelated app on another display.
This is problematic as the focus shift is completely unexpected. Muscle-memory operations like 'shift to App Y and trigger F5' end up on the wrong application, despite App Y sitting right in front of me on the screen. Even worse: 'Move to a new workspace and close existing apps with Alt-F4'.
Also, this is not convenient to work-around, the only way to give focus to the target app is cycling through Alt-tab, which can take a while and is not always straightforward if similar applications (browsers, IDEs) are open.
If I disable
wsmatrrix
and use vanilla gnome-shell workspace-switching the issue does not occur and the focus always ends up on the target workspace.I'm happy to provide more information if required.
The text was updated successfully, but these errors were encountered: