Switch to the I-beam cursor when hovering over the terminal#5028
Switch to the I-beam cursor when hovering over the terminal#5028DHowett-MSFT wants to merge 7 commits intomainfrom
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. |
|
If it is implemented, it should work with the new Beam cursor options.
|
|
@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.) |
zadjii-msft
left a comment
zadjii-msft
left a comment
There was a problem hiding this comment.
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()) |
| 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.
Should we have a helper method that's just "set the PointerCursor to the correct cursor for our current mouse input mode"?
|
So, I think this is your setting:
Cheekiness aside, I'm not averse to speccing a global setting that configures how the cursor works -- but it will be a case of users opting for less expressiveness/fewer features, so we should almost certainly measure its use. |
|
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.
(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.
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? |
ghost
added
Area-TerminalControl
|
Is this still being worked on? |
|
Not actively. |
This comment has been minimized.
This comment has been minimized.
ghost
dismissed
a stale review
via
|
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. |
11 participants
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