After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 762799 - Consider removing the suggestion to not set the cursor visible in non-editable text
Consider removing the suggestion to not set the cursor visible in non-editabl...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Documentation
unspecified
Other Linux
: Normal minor
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-02-27 22:58 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2016-03-05 03:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Joanmarie Diggs (IRC: joanie) 2016-02-27 22:58:47 UTC
The GtkTextView docs [1] state:

  A buffer with no editable text probably shouldn’t
  have a visible cursor, so you may want to turn the
  cursor off.

Doing so, however, means that Orca users giving focus to that widget cannot use caret navigation to access the text unless they toggle cursor visibility on. And it's not always immediately obvious to Orca users how to do this, let alone that it needs to be done in the first place.

While app developers can and will do whatever they see fit, if a developer hasn't independently reached the conclusion that the visible cursor is not desirable, I see no reason to plant the idea in his/her mind. ;)

[1] https://developer.gnome.org/gtk3/unstable/GtkTextView.html#gtk-text-view-set-cursor-visible
Comment 1 Matthias Clasen 2016-02-28 17:06:48 UTC
orca should probably just turn it on on if it is needed for caret navigation.
Comment 2 Joanmarie Diggs (IRC: joanie) 2016-02-28 17:35:31 UTC
Ok, mind telling me how to do so? I don't have the actual Gtk+ widget; I have an accessible (AT-SPI2) object.

If the GtkTextView accessible implemented the action interface (which it currently does not seem to) and provided an action to turn on* the caret, then Orca could do that.

* If you call the action "toggle", then I also need a way to find out if the caret is on or not because I wouldn't want to toggle it off by mistake.
Comment 3 Matthias Clasen 2016-02-29 15:54:23 UTC
would implementing an a11y action for that address your concern ?
Comment 4 Joanmarie Diggs (IRC: joanie) 2016-02-29 16:29:14 UTC
It would lessen my concern. :) It wouldn't do anything for users who need caret navigation and don't use Orca.

A different possibility, which would potentially address the needs of more users and in more applications -- and which would not require individual ATs to manipulate UI -- is what I stated in bug 602526, namely a setting. But if you still do not feel that a setting is the best approach, and you implement an a11y action, then I can at least solve the problem for GtkTextView instances for users of Orca.

Thanks!
Comment 5 Matthias Clasen 2016-03-01 21:24:08 UTC
I could get around to accepting a setting; I think it should probably be more of a general "screen-reader-mode" setting - then we can use it to toggle the annoying selectable labels in message dialogs, too
Comment 6 Joanmarie Diggs (IRC: joanie) 2016-03-01 22:24:49 UTC
Woo hoo! :) Thanks!!

Since this makes me extremely happy, I won't fight over the setting name. But I'll offer for your consideration that something more "caret"- or "keyboard"- or "access"- related might be preferable.

Screen reader users are clearly the main consumer of such a setting, but some screen magnifier users prefer to read text with caret tracking enabled so they don't have to go looking for text which might not be in the current magnified view. And if you cannot use a mouse easily, due to, say, repetitive stress injury, using caret navigation to select the text you wish to copy can be easier.