GNOME Bugzilla – Bug 368640
Allow user to optionally ignore or be notified of tool tips
Last modified: 2007-05-10 14:01:53 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.
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. :-)
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.
[ 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.
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.
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?
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.
> 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?
Plus, I believe we already braille it.
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.
(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.
> 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.
(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. >
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.
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):
+ Trace 133198
self.applyButtonClicked(widget)
settings.setGKSUGrabDisabled(self.disableKeyGrabPref)
raise AttributeError("Widget [" + attribute + "] 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.
Created attachment 87855 [details] full debug.out illustrating the problem from my previous comment
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.
> 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.
Mike/Will, can you confirm this please? If that's the case, I'll investigate further what needs to be done here.
(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.
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.
> 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.
I like DumbIdea(tm) #1. I'm implementing that now. Stay tuned. Thanks!
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.
> 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.
Hi Joanie, When you do do this, with Orca running and generating a full debug.out, do you see any events for tooltips?
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).
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?
> 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!
Cool. Thanks Will. Closing as FIXED.