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 368640 - Allow user to optionally ignore or be notified of tool tips
Allow user to optionally ignore or be notified of tool tips
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
2.17.x
Other All
: Normal enhancement
: 2.20.0
Assigned To: Rich Burridge
Orca Maintainers
Depends on: 368626
Blocks:
 
 
Reported: 2006-11-01 01:06 UTC by Willie Walker
Modified: 2007-05-10 14:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to implement this feature. (4.60 KB, patch)
2007-05-09 00:42 UTC, Rich Burridge
none Details | Review
full debug.out illustrating the problem from my previous comment (405.54 KB, text/plain)
2007-05-09 04:22 UTC, Joanmarie Diggs (IRC: joanie)
  Details
Revised version of the patch. (4.60 KB, patch)
2007-05-09 05:31 UTC, Rich Burridge
none Details | Review
Further revision to try to also handle tooltip events when user presses Control-F1 (5.68 KB, patch)
2007-05-09 16:09 UTC, Rich Burridge
needs-work Details | Review
Revised patch to ignore tooltip events if > 200ms older than current time. (6.66 KB, patch)
2007-05-09 21:23 UTC, Rich Burridge
committed Details | Review
the full debug.out I meant to create and attach. D'oh! (58.62 KB, text/plain)
2007-05-10 03:00 UTC, Joanmarie Diggs (IRC: joanie)
  Details

Description Willie Walker 2006-11-01 01:06:38 UTC
Orca currently does nothing when a tool tip is popped up.  It should do *something*, such as speak/braille the tool tip and/or move the magnifier region of interest to the tool tip.
Comment 1 Joanmarie Diggs (IRC: joanie) 2006-11-19 18:43:18 UTC
I agree that this is important functionality.  However, once this is implemented, I'd like to suggest there be a setting somewhere in the Orca Preferences dialog through which one could control whether or not to ignore tool tips. While one should always be able to access them, one might not always want to exercise that ability. :-)
Comment 2 Mike Pedersen 2007-04-05 17:39:04 UTC
What I'd like to see is a check box on the general tab to toggle weather or not we speak and braille tooltips when the mouse hovers over icons.  The user will always want to hear tooltips if they are present when they press CTRL+f1.  
Comment 3 Lynn Monsanto 2007-04-05 18:13:18 UTC
[ Comments by Will Walker in email. ]

We should probably add a 'Ignore tool tips' checkbox to the General page of the preferences dialog that can be used to set the new settings.presentToolTips property added via bug 368626.

Mike should then comment on whether that type of UI feature is the right thing to have.  If it is something Mike approves of, adding this feature should be a task that takes less than 4 hours. 

One thing that could lengthen the task might be whether we want to spec the ignoring of tooltips to be along the lines of only ignoring tooltips if they are caused by a mouse hover.  In this case, a value of False for presentToolTips might end up meaning "don't present them if the pop up was caused by the mouse, but do present them if the user performed and explicit keyboard action to pop them up."  This might add a couple lines of code to the tooltip handling code: if presentToolTips is False, still present them if the last keystroke was an F1, which was an explicit user action to pop the tool tip up.
Comment 4 Rich Burridge 2007-05-02 20:08:54 UTC
I think this is one of those enhancement requests that is < 4 hours,
if we can fully spec out what the one of more new checkbox options
should be on the General pane. 

Mike, that's where you come in. Could you please look at the
previous comments and tell us what needs to be done here?

Thanks.
Comment 5 Rich Burridge 2007-05-02 23:36:02 UTC
Note that we discuss above about putting this tooltip checkbox
on the General page. As we are not displaying the General page
for Application specific settings, and as this type of setting
I think falls into that category, should it be placed on the 
Speech page? Or do we need a new tab for things like this?
Comment 6 Mike Pedersen 2007-05-03 00:27:04 UTC
I think this should be on the speech tab because we won't be brailling this information just speaking it.  Lets just add a "speak tooltips" checkbox.  
Comment 7 Joanmarie Diggs (IRC: joanie) 2007-05-03 00:32:05 UTC
> I think this should be on the speech tab because we won't be brailling this
> information just speaking it.  Lets just add a "speak tooltips" checkbox.  

To play devil's advocate, what about folks who want to see how the tooltip contents are spelled?  What about folks who are deaf-blind?

Comment 8 Willie Walker 2007-05-03 00:59:06 UTC
Plus, I believe we already braille it.
Comment 9 Mike Pedersen 2007-05-03 00:59:31 UTC
If we want to do this we'll need to provide another way to get at tooltips.  I really don't want tooltips causing the braille focus to move.  Perhaps we should allow the user to get the tooltip when moving the mouse with flat review.  Perhaps an extention of "where am I".  I just really want to minimize messing with the braille focus.  
Comment 10 Mike Pedersen 2007-05-03 01:04:39 UTC
(In reply to comment #8)
> Plus, I believe we already braille it.
>
Yes and I've really been thinking that this is the wrong approach.  I think this is going to be a real problem when we implement watched objects as well.  Moving braille focus is going to have to be a separate option for users to set. 

Comment 11 Willie Walker 2007-05-03 01:09:56 UTC
> If we want to do this we'll need to provide another way to get at tooltips.  I
> really don't want tooltips causing the braille focus to move.  

I'm pretty sure we discussed this on the phone.  When tool tips popped up, you wanted them spoken and brailled.  That's what we do now.  Since there is obviously confusion and a possible change of heart, this sounds like a discussion to take to the Orca users list. It seems like the main things to discuss are what the desired user interaction models should be for tool tips and for watched objects.
Comment 12 Mike Pedersen 2007-05-03 01:31:44 UTC
(In reply to comment #11)
> > If we want to do this we'll need to provide another way to get at tooltips.  I
> > really don't want tooltips causing the braille focus to move.  
> 
> I'm pretty sure we discussed this on the phone.  When tool tips popped up, you
> wanted them spoken and brailled.  That's what we do now.  Since there is
> obviously confusion and a possible change of heart, this sounds like a
> discussion to take to the Orca users list. It seems like the main things to
> discuss are what the desired user interaction models should be for tool tips
> and for watched objects.
Yes it's true this is what I origionally said.  After more testing and thought I think I was wrong which is why I think we should make moving the braille focus an option.  
> 

Comment 13 Rich Burridge 2007-05-09 00:42:21 UTC
Created attachment 87849 [details] [review]
Patch to implement this feature.

Patch not committed yet. I've put the new checkbox at
the bottom of the set of widgets on the General pane.
Mike, please let me know if you want it somewhere else.

This seems to work nicely for me, but please let me know
if you find any problems.
Comment 14 Joanmarie Diggs (IRC: joanie) 2007-05-09 04:20:35 UTC
Hey Rich.

I did the following:

1. Launched Orca from gnome-terminal
2. Pressed Insert Space.

At this point Orca said it might take a while.  After it took longer than I would expect it to take:

3. Pressed Insert Space again.

At this point I got the Preferences dialog

4. Pressed Alt P for Present Tooltips followed by Alt O for the OK button  and space to press it.

This error appeared in the terminal window:

Traceback (most recent call last):
  • File "/usr/lib/python2.5/site-packages/orca/orca_gui_prefs.py", line 2184 in okButtonClicked
    self.applyButtonClicked(widget)
  • File "/usr/lib/python2.5/site-packages/orca/orca_gui_prefs.py", line 2150 in applyButtonClicked
    settings.setGKSUGrabDisabled(self.disableKeyGrabPref)
  • File "/usr/lib/python2.5/site-packages/orca/orca_glade.py", line 61 in __getattr__
    raise AttributeError("Widget [" + attribute + "] not found")
AttributeError: Widget [disableKeyGrabPref] not found

And this one in debug.out:

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/orca/orca.py", line 977, in _showPreferencesGUI
    module.showPreferencesUI()
  File "/usr/lib/python2.5/site-packages/orca/orca_gui_prefs.py", line 2217, in showPreferencesUI
    OS._init()
  File "/usr/lib/python2.5/site-packages/orca/orca_gui_prefs.py", line 277, in _init
    self._initGUIState()
  File "/usr/lib/python2.5/site-packages/orca/orca_gui_prefs.py", line 988, in _initGUIState
    prefs["presentToolTips"] and settings.canPresentTooltips)
AttributeError: 'module' object has no attribute 'canPresentTooltips'

Full debug.out to follow.
Comment 15 Joanmarie Diggs (IRC: joanie) 2007-05-09 04:22:09 UTC
Created attachment 87855 [details]
full debug.out illustrating the problem from my previous comment
Comment 16 Rich Burridge 2007-05-09 05:31:12 UTC
Created attachment 87856 [details] [review]
Revised version of the patch.

Thanks joanie.

I had canPresentTooltips instead of canPresentToolTips in a couple of
places. That has causing a traceback before self.disableKeyGrabPref was
being set in _initGUIState() in orca_gui_prefs.py.

This version should hopefully fix both of the tracebacks.

Not committed yet.
Comment 17 Joanmarie Diggs (IRC: joanie) 2007-05-09 07:55:35 UTC
> This version should hopefully fix both of the tracebacks.

Yup! Thanks.

On another note, it seems as though we're treating all tooltips as equal regardless of whether or not they appeared due to mouse hovering or pressing Control+F1.  I thought the intent was that if the checkbox were not checked, we'd still speak those that resulted from Control+F1.
Comment 18 Rich Burridge 2007-05-09 14:03:44 UTC
Mike/Will, can you confirm this please? If that's the case, I'll
investigate further what needs to be done here.
Comment 19 Willie Walker 2007-05-09 14:22:58 UTC
(In reply to comment #18)
> Mike/Will, can you confirm this please? If that's the case, I'll
> investigate further what needs to be done here.
> 

Yes - if the tooltip was brought up by some explicit keyboard command (e.g., Ctrl+F1), then it should be presented no matter what the preference setting is.
Comment 20 Rich Burridge 2007-05-09 16:09:39 UTC
Created attachment 87889 [details] [review]
Further revision to try to also handle tooltip events when user presses Control-F1

I've tried to add in the ability to always speak tooltip messages
when the user presses Control-F1, irrespective of the "present
tooltips" setting, but the current approach I'm using isn't totally
working.

In _processObjectEvent() in focus_tracking_presenter.py, if we
are getting a ROLE_TOOL_TIP event, I check to see if the last
input event was a keyboard event with an event string of F1. If
it is, then that tooltip is always spoken.

The problem here is that nudging the mouse (i.e. mouse move events)
aren't updating orca_state.lastInputEvent, so that's still set to
a keyboard event with an "F1" event string, so it then goes and speaks
those tooltip events as well now.

Will is there a better way of handling this?

Note we will also have the same problem currently being discussed
in bug #435201, namely that the last keyboard event of a Control-F1
pair might not be the F1 key. When we have a solution there, we can come
back and adjust the fix for this bug too.
Comment 21 Willie Walker 2007-05-09 19:07:24 UTC
> The problem here is that nudging the mouse (i.e. mouse move events)
> aren't updating orca_state.lastInputEvent, so that's still set to
> a keyboard event with an "F1" event string, so it then goes and speaks
> those tooltip events as well now.
> 
> Will is there a better way of handling this?

No brilliant ideas.  Here's a couple dumb ideas, though.  I'm always good for those.  :-)

1) Compare the 'time' field of the keyboard event with the current time and only present the tooltip if the tooltip event appears within some small time delta (e.g., 200ms).  I suspect this would eliminate a lot of the mistaken presentations due to mouse nudging, but not all of them.

2) The first time you present a tooltip because of a keyboard event, annotate the event with a "been there done that" flag.  Something like orca_state.lastInputEvent.showedTooltip = True.  If the "been there done that" flag is present, then don't show the tooltip.  This might catch all the problems.

> Note we will also have the same problem currently being discussed
> in bug #435201, namely that the last keyboard event of a Control-F1
> pair might not be the F1 key. When we have a solution there, we can come
> back and adjust the fix for this bug too.

Definitely. 
Comment 22 Rich Burridge 2007-05-09 20:48:45 UTC
I like DumbIdea(tm) #1. I'm implementing that now. Stay tuned.
Thanks!
Comment 23 Rich Burridge 2007-05-09 21:23:33 UTC
Created attachment 87916 [details] [review]
Revised patch to ignore tooltip events if > 200ms older than current time.

Patch committed. I think we are pretty close now.
Bug put into "[pending]" state.

Comments please.
Comment 24 Joanmarie Diggs (IRC: joanie) 2007-05-10 02:02:41 UTC
> Comments please.

Seems to work very nicely.  The only thing I noticed -- which might not be us -- is that we don't speak the tooltips on toolbars initially in apps.  Try this -- and don't click on anything until it's called for in the steps! :-)

0. Prep:  Be sure present tooltips is enabled.
1. Launch Orca using the keyboard
2. Launch one of the following apps using the keyboard:  Gedit, OOo Writer, Evolution
3. *WITHOUT CLICKING ON ANYTHING* hover the mouse over the buttons on the app's toolbar.

The tooltips are not spoken

4.  Now you may click. :-)  Click somewhere in the window (e.g. like on the empty document)
5. Hover the mouse over the buttons on the app's toolbar.

This time they will be spoken as expected.  I can reproduce this pretty reliably.
Comment 25 Rich Burridge 2007-05-10 02:23:17 UTC
Hi Joanie,

When you do do this, with Orca running and generating a full debug.out,
do you see any events for tooltips?
Comment 26 Joanmarie Diggs (IRC: joanie) 2007-05-10 03:00:49 UTC
Created attachment 87928 [details]
the full debug.out I meant to create and attach.  D'oh!

> When you do do this, with Orca running and generating a full debug.out,
> do you see any events for tooltips?

I knew there was *something* I was forgetting to do....  :-) Sorry, and thanks for the reminder!

We're still getting related events it seems, namely:
* object:state-changed:showing
* object:state-changed:visible
* object:state-changed:iconified

Compare when it's not working (lines 805-1055) to when it is (1106-1232).
Comment 27 Rich Burridge 2007-05-10 13:47:52 UTC
I had a look at this. We are not getting any events for objects of role
"tool tip" until line 1106 in the debug.out file:

vvvvv PROCESS OBJECT EVENT object:state-changed:showing vvvvv
OBJECT EVENT: object:state-changed:showing             detail=(1,0)
---------> QUEUEING EVENT object:state-changed:iconified
    app.name='gedit'              name='Save the current file' role='tool tip' state='ENABLED SENSITIVE SHOWING VISIBLE' relations='POPUP_FOR'

Therefore we can't do our thang and check to see if we can announce them.

As you say, this is not us and is beyond our control.

I think this bug is ready to close out. Mike/Will, do you agree?
Comment 28 Willie Walker 2007-05-10 13:51:20 UTC
> I had a look at this. We are not getting any events for objects of role
> "tool tip" until line 1106 in the debug.out file:
> ...
> As you say, this is not us and is beyond our control.
> ...
> I think this bug is ready to close out. Mike/Will, do you agree?

I think so.  Thanks!
Comment 29 Rich Burridge 2007-05-10 14:01:53 UTC
Cool. Thanks Will. Closing as FIXED.