microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
95.09k stars 8.24k forks source link

Feature request: Input focus follows mouse #5258

Open LookoutHill opened 4 years ago

LookoutHill commented 4 years ago

Description of the new feature/enhancement

Focus follows mouse allows one to direct input into the exposed terminal tab while another window is selected so long as the mouse pointer is positioned anywhere over the Windows Terminal window.

This will reduce extra mouse clicks and make switching input focus more streamlined.

Proposed technical implementation details (optional)

Given that another window is selected and active, focus follows mouse allows one to direct input into the exposed terminal tab when the mouse pointer is positioned anywhere over the Windows Terminal window. One does not have to click on the Windows Terminal window to active input focus.

DHowett-MSFT commented 4 years ago

Yeah, this is a neat feature request. I'm marking it up for terminal/UI/backlog and that it needs a specification :smile:

zadjii-msft commented 2 years ago

Huh, so this is different from #6459 (which was added in Windows Terminal Preview v1.7.572.0). For this, we just need to focus the window when the get a mouse hover event, even when the Terminal isn't focused. I suppose a "window"/global setting for "focusOnHover":bool would be easy enough (so long as we get the right window message even when inactive. Don't think we need a whole spec for this one.

alceu-frigeri commented 2 years ago

If I may, 'focus follows the mouse' is kind of already implemented (although oddly named) : control panel -> ease of access -> ease of access center -> make the mouse easier to use -> activate a window by hovering over it ...

which 'sucks' because, once you activate this option, wherever you move the mouse, the hovering window comes to top, completely disrupting (at least for me) my workflow.

It would be really nice if the focus would follow the mouse BUT without bringing the focused window to the top (allowing one to type/input in a partially covered window). btw, this is the behavior one can have in Linux KDE (Xwindows).

Even better if one had the added option to tell windows "bring the window to the top ONLY IF the user click the top bar, but not otherwise"

b- commented 2 years ago

[...] which 'sucks' because, once you activate this option, wherever you move the mouse, the hovering window comes to top, completely disrupting (at least for me) my workflow.

It would be really nice if the focus would follow the mouse BUT without bringing the focused window to the top (allowing one to type/input in a partially covered window). btw, this is the behavior one can have in Linux KDE (Xwindows).

@alceu-frigeri try this

I use it all the time.

alceu-frigeri commented 2 years ago

[...] which 'sucks' because, once you activate this option, wherever you move the mouse, the hovering window comes to top, completely disrupting (at least for me) my workflow. It would be really nice if the focus would follow the mouse BUT without bringing the focused window to the top (allowing one to type/input in a partially covered window). btw, this is the behavior one can have in Linux KDE (Xwindows).

@alceu-frigeri try this

I use it all the time.

Thanks, I kind of knew that, through registry you can force that behavior, the problem with solutions of the kind 'you have to remember to adjust it in the registry', and some times it isn't an option (corporate PCs), that's why I tried to ask: 'make it an UI option'.

b- commented 2 years ago

[...] which 'sucks' because, once you activate this option, wherever you move the mouse, the hovering window comes to top, completely disrupting (at least for me) my workflow. It would be really nice if the focus would follow the mouse BUT without bringing the focused window to the top (allowing one to type/input in a partially covered window). btw, this is the behavior one can have in Linux KDE (Xwindows).

@alceu-frigeri try this I use it all the time.

Thanks, I kind of knew that, through registry you can force that behavior, the problem with solutions of the kind 'you have to remember to adjust it in the registry', and some times it isn't an option (corporate PCs), that's why I tried to ask: 'make it an UI option'.

I understand, but I don't think the teams responsible for Windows's own settings are anywhere near this GitHub issue page. I recommend filing a report in Feedback Hub (and if you link it here I'll vote on it!). But I personally just install that silly WinAero Tweaker app and use that, or it would be relatively trivial to write a small C++ application that computes and applies the correct settings. You absolutely don't need administrator access to change those registry settings. (Former sysadmin)

alceu-frigeri commented 2 years ago

[...] which 'sucks' because, once you activate this option, wherever you move the mouse, the hovering window comes to top, completely disrupting (at least for me) my workflow. It would be really nice if the focus would follow the mouse BUT without bringing the focused window to the top (allowing one to type/input in a partially covered window). btw, this is the behavior one can have in Linux KDE (Xwindows).

@alceu-frigeri try this I use it all the time.

Thanks, I kind of knew that, through registry you can force that behavior, the problem with solutions of the kind 'you have to remember to adjust it in the registry', and some times it isn't an option (corporate PCs), that's why I tried to ask: 'make it an UI option'.

I understand, but I don't think the teams responsible for Windows's own settings are anywhere near this GitHub issue page. I recommend filing a report in Feedback Hub (and if you link it here I'll vote on it!). But I personally just install that silly WinAero Tweaker app and use that, or it would be relatively trivial to write a small C++ application that computes and applies the correct settings. You absolutely don't need administrator access to change those registry settings. (Former sysadmin)

to make it short: yes, I know that there are ways 'to force that behavior', and yes too, I already 'posted a request in the feedback hub' (and same 'nonresponse response' as here. If you have the knowledge to edit the registry, go for it. do it, be happy. I'm too old to have to keep a tab of what registry do I have to set to which hidden feature in said version. nonsense (like trying to convince someone that never used a project-based system manager that using one is nice: 'too complicated')