Skip to content
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

Feature request: Input focus follows mouse #5258

Open
LookoutHill opened this issue Apr 6, 2020 · 7 comments
Open

Feature request: Input focus follows mouse #5258

LookoutHill opened this issue Apr 6, 2020 · 7 comments
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal.
Milestone

Comments

@LookoutHill
Copy link

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.

@LookoutHill LookoutHill added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Apr 6, 2020
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Apr 6, 2020
@DHowett-MSFT
Copy link
Contributor

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

@DHowett-MSFT DHowett-MSFT changed the title Input focus follows mouse Feature request: Input focus follows mouse Apr 8, 2020
@DHowett-MSFT DHowett-MSFT added Area-User Interface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. Product-Terminal The new Windows Terminal. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Apr 8, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Apr 8, 2020
@DHowett-MSFT DHowett-MSFT added this to the Terminal Backlog milestone Apr 8, 2020
@zadjii-msft
Copy link
Member

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.

@zadjii-msft zadjii-msft added Issue-Task It's a feature request, but it doesn't really need a major design. and removed Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. labels Nov 22, 2021
@zadjii-msft zadjii-msft modified the milestones: Terminal Backlog, Backlog Jan 4, 2022
@alceu-frigeri
Copy link

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-
Copy link

b- commented Sep 14, 2022

[...] 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
Copy link

[...] 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-
Copy link

b- commented Sep 15, 2022

[...] 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
Copy link

[...] 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')

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

5 participants