Repository navigation
Mouse pointer should be text and not arrow one #1441
Description
Expected behavior
The mouse pointer used should be the text cursor (Ꮖ) one since text is selectable, not the default arrow (↖) pointer.
Actual behavior
It's the default arrow pointer that's used.
Reacted by Poopooracoocoo, Matteo Contrini, Kirill, sqqqs, ivin, Matt Johnston, Paulo Gomes, Nicolas Ramz, Melissa, Stephen Workman and 12 more
Reacted by David Rettenbacher, Avunia Takiya and Carl Walsh
Activity
[-]Pointer should be text and not arrow one[/-][+]Mouse pointer should be text and not arrow one[/+]JushBJJ commentedon Jun 23, 2019
#1375
DHowett-MSFT commentedon Jun 26, 2019
Probably correct.
liangrongjie commentedon Aug 6, 2019
I very much hope that the mouse pointer is always text cursor (Ꮖ), even if no text is selected; Just like git-bash and cygwin.
liangrongjie commentedon Aug 6, 2019
Is there any way to configure a text mouse pointer is text cursor (Ꮖ), ? Just like git-bash and cygwin.
matteocontrini commentedon Sep 29, 2019
Just to make sure that I'm not missing anything, there's currently no option for this, right?
14 remaining items
matteocontrini commentedon Nov 3, 2022
Is there any chance for this to be implemented? Thanks
zadjii-msft commentedon Nov 3, 2022
Matteo Contrini (@matteocontrini) not any time immediately soon. There was an attempt in #5028, but we ran into some fundamental issues with WinUI that prevented us from getting that across the finish line. We were under the impression that this wouldn't be a solvable problem before WinUI 3 (which we're not likely to move to any time soon).
I'd LOVE to see someone take that branch and prove me wrong!
4wk- commentedon Mar 6, 2023
I also would love the Ꮖ cursor to be set by default, but yeah an option is the better way here to let users decide. I don't have the skill to do this, unfortunately; but that's one of the time I wish Github could allow user to put bounties on tasks 😄 to attract more contributors and help Dustin L. Howett (@DHowett) attempt! Cheers
mailinglists35 commentedon Nov 19, 2023
This is one of the strongest arguments
When the underlying console app DOES have mouse support, it signals the terminal (I don't know how it happens behind the scenes) and the terminal CHANGES the cursor from I-beam pointer to OS/DE defined arrow pointer. This in turn signals the user that it can or can not freely type into the area where the mouse is an arrow, or more exactly the user knows that when the cursor is arrow, the key presses are NOT sent ad-literam to the app, but instead at most they can be interpreted as command shortcuts to the app.
This UI convention has existed for years, I think even since Windows 3.11: programs that work with text input are responsible for changing the mouse cursor from arrow to I-beam when mouse is hovering or moving over the text input area. The only other case when the mouse cursor is changed from arrow to I-beam is when there is selectable text available, even if the text input is not available.
Windows Terminal should make no exception from this convention and has no reason not to: it's an app that has 90%+ of its area working with text, both input and selectable. Additionally, when the app running inside the terminal signals that it has full mouse support, it MUST change the cursor from I-beam to arrow.
Sure it can be argumented "it's overly complicated at this stage", but this should be a clearly declared goal of the app. Not "hm, it's debatable, hm, oh it's so complicated technically that we might just let it low in the priority queue".
This should be among top priority tasks for a Terminal app.
mailinglists35 commentedon Nov 19, 2023
warpdesign commentedon Nov 19, 2023
zadjii-msft commentedon Nov 20, 2023
There's no debate as to if we should do this or not. For those who read the thread, as I mentioned before (#1441 (comment)), we tried to do this a couple years back (in #5028), and ran into fundamental flaws in WinUI. We'd love if someone could prove us wrong though!
control: use the I-beam pointer over the text area