-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Switch to the I-beam cursor when hovering over the terminal #5028
Conversation
This commit makes us use the I-beam cursor when the user hovers over the terminal, *unless* mouse mode is enabled. I've also plumbed up a bunch of events so that: * If mouse mode is _toggled_ while hovering, the cursor will switch to the arrow if it's on or the I-beam if it's off. * If you hold down shift to suppress mouse mode, the cursor will switch back to the I-beam. Fixes #1441.
On a scale of yes to no, could this be made a setting (in a future PR) so I could disable this? Should it be a global or a profile setting? |
In a future PR, it could probably be made a setting -- global, though. |
@mdtauk that is not an i-beam mouse cursor. whatever that is works with Terminal as of v0.10 (or v0.11? which is not yet out; it merged recently.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm okay with this, on one condition. I'd like to have a plan for what we're going to call the setting to disable this before we ship this, cause I'm a pointer kind of guy 😝
{ | ||
// If the current focused element is a child element of searchbox, | ||
// we do not send this event up to terminal | ||
if (_searchBox && _searchBox->ContainsFocus()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably this bit would go away with #4748?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep!
if (_oldCursor) // if we have an active cursor transition | ||
{ | ||
auto coreWindow = Window::Current().CoreWindow(); | ||
coreWindow.PointerCursor(_CanSendVTMouseInput() ? _pointerCursor : _textCursor); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have a helper method that's just "set the PointerCursor
to the correct cursor for our current mouse input mode"?
This is in selfhost. Give it a feel. |
|
showerthought: what if we just always turned the cursor back into an arrow, then let the new control change it to whatever they want? Presumably one control's Additionally: Are we planning on putting this is 1.0? |
not sure about 1.0. My concern with always setting Arrow is that what if they're hovering with a pen? I dunno, I kinda wanna ask AustinL. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
So this is about the mouse pointer (mouse cursor), and not the text insertion cursor. I legit had to read the thread halfway through to realize it. Don't you guys always confuse these two? I do. Similar names, the word "cursor" overloaded for them, and both possibly being of "I-beam" shape. My preference is to say "mouse pointer" for, well, that one; without using the word "cursor". Do you guys have a preferred terminology? |
@egmontkob yep, this is about the mouse pointer. I should endeavour to be better about saying "pointer" when I mean the thing the user points with. 😄 Alas, overloaded terms are pervasive in our industry. They're so hard to escape. |
(And yeah, we get them mixed up all the time.) |
winrt::Windows::UI::Core::CoreCursor _textCursor; | ||
winrt::Windows::UI::Core::CoreCursor _pointerCursor; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Correct me if I'm wrong) It looks like you only set these in the constructor. Why not just make them constexpr
in the namespace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
they're winrt objects. it sucks.
The conflicts shouldn't be hard to resolve |
All the decent Terminals I know have this behavior: when the mouse pointer is over them it changes into a sort of |
And you are commenting on this open pull request that does exactly this so as to move it along? |
Is this still being worked on? |
Not actively. |
This comment has been minimized.
This comment has been minimized.
34f83a6
Closing as it's super stale, but not deleting the branch in case someone wants to dig it up again one day. |
To add some notes that never made it here a few years back: I believe there was no good way for us to set the mouse pointer for a single control in XAML. A control could change the cursor in PointerEntered, but IIRC there's a race between PointerEnter's and PointerExits. So when you've got an app that's got all sorts of mixed UI elements, some that want the cursor to be an I-beam and some that want the arrow, well now you're stuck. As you hover over different elements, they'll fight over who's actually setting the cursor to what. |
This commit makes us use the I-beam cursor when the user hovers over the
terminal, unless mouse mode is enabled. I've also plumbed up a bunch
of events so that:
the arrow if it's on or the I-beam if it's off.
back to the I-beam.
Fixes #1441.
Detailed Description of the Pull Request / Additional comments
It turns out that we're in violation of the Windows human interface guidelines, so that's good.
It also turns out that you cannot set the cursor type of a control -- you actually have to actively set and reset the cursor when the pointer enters or exits.
my selection color is bright red to differentiate it from vim's mouse mode selection