GNOME Bugzilla – Bug 462256
Orca doesn't speak/braille anything when going to the 2nd screen in the OOo Presentation startup wizard.
Last modified: 2007-08-14 13:45:27 UTC
Steps to reproduce: 1/ Start up Orca 2/ Start up OOo-dev 2.3.0 Presentation application (simpress) 3/ Make sure that the "Empty Presentation" radio button is selected (the default) and focus is on the "Next" button and press Space. The wizard will now display the second screen (asking you to select a slide design), but Orca didn't speak/braille anything. This is probably YAOOoB, and it's not giving up any events to work with. We might be able to hack something up in the StarOffice.py script. I seem to remember there was a similar problem with one of the other OOo wizards. Full Orca debug.out to be attached.
Created attachment 92815 [details] Orca debug.out generated whilst testing this problem.
It's as I thought. We don't get any useful accessibility event when the second screen of the startup wizard is displayed. All we get are: ---------> QUEUEING EVENT object:property-change:accessible-name ---------> QUEUEING EVENT object:property-change:accessible-name ---------> QUEUEING EVENT object:property-change:accessible-name ---------> QUEUEING EVENT object:property-change:accessible-name ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:children-changed:add ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:state-changed:sensitive ---------> QUEUEING EVENT object:state-changed:enabled ---------> QUEUEING EVENT object:state-changed:checked ---------> QUEUEING EVENT object:state-changed:checked I'll file an OOo bug on this. I don't think it's going to be easy to work around it in the StarOffice.py script, but I'll check that next.
I've opened up OOo issue #80234 on this. http://www.openoffice.org/issues/show_bug.cgi?id=80234
Looks like the StarOffice/OpenOffice accessible application name has changed yet again with OOo-dev 2.3.0 to "soffice". Sigh. We are going to need to add a: setScriptMapping(re.compile(_('soffice')), "StarOffice") in settings.py.
Created attachment 92819 [details] [review] Patch to show how we could hack around this problem. We could certainly detect when we get this situation, with something like the following patch, but it's yet another case where we have to compare against a localized string. Note that this will just speak/braille "Next button" when we go to the second screen. Assuming we want to do this, do we want to do anything more? Note that we current only say "Next button" for the 1st screen, because that's the object that initially has focus, so we are being consistent. It's just not obvious how you can tell you are on the second screen. The "2." is part of a graphic image.
(In reply to comment #4) > Looks like the StarOffice/OpenOffice accessible application name has > changed yet again with OOo-dev 2.3.0 to "soffice". Sigh. > > We are going to need to add a: > > setScriptMapping(re.compile(_('soffice')), "StarOffice") > > in settings.py. > The good thing is that I think they understand the problems of doing this and that this will be the last name change -- there was an OOo bug tracking the name change problem, but I cannot seem to find it.
When this gets changed in trunk could it also get changed in 2.20? OO2.3 will be shipping in gutsy with gnome2.20.
It's going to add a new string (the way it's currently written), so if we want to do this for 2.20, we need to do it very soon. I therefore need to know if the suggested approach is the right approach.
I don't personally think this is worth the trouble. If you press tab or try flat review you immediately have a pretty good idea where you are. If we get the problem fixed in 2.22 I think that's just fine.
I don't think we should push for GNOME 2.20 on this one. Instead, let's do the ooimpress work on HEAD and opportunistically get fixes into the gnome-2-20 branch where is makes sense (e.g., they represent a good bug fix in Orca). But, having said that, we should definitely get the settings.py fix in for GNOME 2.20. Rich, can you please add that to settings.py? For the GNOME 2.22 timeframe, I'd like to see OOo fix the bug and not require us to hack around it. Does their schedule show anything that looks like a release where they might be able to have a fix by the time GNOME 2.22 goes out?
setting.py change applied to gnome-2-20 branch and HEAD. String change message sent to the GNOME I18N folks. I'm still refining the workaround for getting it to speak "Next button" for the 2md (and subsequent) screens. At the moment, it's speaking it twice.
Created attachment 92865 [details] [review] Refined patch. I've adjusted the patch to check for a SENSITIVE state. We now only hear "Next button" spoken once as we get the second screen displayed. I then foolishly tried to press Space to move to the third screen, and the Next button disappeared and everything hung. I'll file YAOOoB for that and track it with another Orca bug.
Patch committed to SVN HEAD. Setting the bug into a "[pending]" state.
I think this one looks good.
Thanks Mike. Closing as FIXED.