- General
-
Bugs
Stop the main window from being auto-raised when activated
Stop the windows from being raised when only activated - instead, the sidebar should only be raised when Chrome is raised.
I'm a long time user of TweakUI / X-mouse. Now I'm on Windows 7 and I've enabled "Activate a window by hovering over it with the mouse" in the "Make the mouse easier to use" section of the "Ease of Access Center".
My expectation is that windows will not be auto-raised when getting the focus, however this is happening with Chrome if I've selected the Sideways option for "Keep sidebar visible next to dock window".
This is very frustrating because the "Keep sidebar visible next to dock window" is the major reason I use Sideways over Tabs Outliner (I prefer a dark theme), but I can't use this feature because Chrome keeps covering my instant message windows, email windows, and every other non-maximized window as soon as the mouse pointer passes over chrome on the way to the non-maximized window.
Answer
Will look into a solution for this. Chrome unfortunately doesn't provide the best support for detecting and performing window raise & focus operations, but I'll see what can be done.
Chrome unfortunately doesn't provide the best support for detecting and performing distinct window raise & focus events, but I'll see what can be done.
I see what you mean about the window API being limited.. It looks like onFocusedChanged is the only related event, and "focused" the only related window property.
Given these limitations I'm guessing the current implementation hooks into the onFocusChanged and then toggles the alwaysOnTop property in order to raise the window? Why is the main window getting raised though, and not just Sidewise? It wouldn't be so bad if it were only the Sidewise window.
Thanks for the quick response too!
Actually, Chrome doesn't let us set alwaysOnTop for windows; that is a readonly properly. The solution is basically to focus() the main Chrome window then [re]focus() the Sidewise window.
Or vice versa: when the main Chrome window gets focused, we focus() the sidebar and then refocus() the main Chrome window so that the window the user focused will be the one focused after the "raise" is done. If this is not done, then whenever the main Chrome window is focused, we would (raise and) switch focus to the sidebar -- leaving the main Chrome window unfocused.
What if I added an option to prevent that second refocus()? So when the main Chrome window gets focused by the user (while a non-Chrome app has the focus), we would focus() the sidebar, but leave the focus there. If the user actually wants the main Chrome window focused, then they would have to manually click it (and since a Chrome window already is focused here, we would not do any more automatic focus()ing).
Then it would take two clicks (or with XMouse, a main-window hover followed by a sidebar-hover followed by a hover back to the main window) to get the main window focused.
Do you think that would be useful?
As you have probably gathered, this whole scenario is a total hack, and the addition of a raise() function in Chrome would eliminate almost all of this workaround code.
Another option to consider is turning off your "keep sidebar visible" option and setting the "when browser button is clicked" option to "dock sidebar to window". Then you don't get sidebar auto-raising, but you can still do it manually by clicking the Sidewise button next to the address bar.
Lastly, I'll mention that I used to be an XMouse user, but for me I have found something better which I will call XScroll. All this does is send mousewheel events to the window that the pointer is over rather than the focused window; mousing over a window doesn't raise it. It's not quite as nice as the full XMouse functionality (i.e. being able to type to a non-top window), but the scrolling aspect is the part I used most wrt XMouse, and the XScroll strategy avoids a lot of the potential downsides and quirks of what XMouse does in certain applications. Let me know if you're interested.
Thanks again for the detailed followup. It really does sound like a hack. That the Chrome focus method raises the window at all is the main problem, and I don't see an easy solution given the limitations of the API.
I think that your proposal to prevent the second refocus could work. Call it the "XMouse" option. It could work like you've described, but I think it might need one tweak.
Consider: pointer enters the main Chome window. onFocus is called and focuses Sidewise for the window raise side-effect, leaving sidewise both focused and raised. The pointer, however, is not moved and is still at the edge of the Chrome window. As the user continues movement over the chrome window, XMouse gives focus back to the main window, and the cycle repeats, each time leaving focus over Sidewise. That's no good, as the two would be fighting for focus. As you said, the user would have to click the main window to break this cycle. And clicking is the opposite of XMouse.
So to finish the hack, only give focus to the Sidewise bar if it wasn't already focused within the last few seconds.
If this is all too hack-y then I'll completely understand and will continue to use other options you've mentioned.
Another possibility occurred to me, though I don't know how feasible it is:
Do the focus sidewise - focus main window combination when the user clicks anywhere in the browser - tabs, bookmarks, navigation buttons, etc. This would make clicking anywhere the equivalent of clicking the sidewise button. Again you may need some state to know if focus had ever left the Chrome window because I think you want to avoid doing these focus events unnecessarily in order to minimize the alt-tab ordering problems.
Lastly, while XScroll sounds interesting, the only reason I use XMouse is to enter text without having to click the window first.
thanks again-
Customer support service by UserEcho
Chrome unfortunately doesn't provide the best support for detecting and performing distinct window raise & focus events, but I'll see what can be done.