GNOME Bugzilla – Bug 646288
Orca needs to set and respond to the appropriate gsettings keys
Last modified: 2013-01-09 11:12:16 UTC
I used the 'Screen Reader' switch in the universal access panel to enable orca. It did start saying something, then things went unresponsive, the shell stopped redrawing, and eventually I had to kill my session from a vt. After I logged back in orca was running seemingly normal, and spoke to me about gnome-shell and other windows. But setting the switch back to off did not stop orca.
This is probably going to wind up being several smaller bugs and possibly some upstream + some downstream work. But I'll jot things down here and spawn bugs as needed. On Fedora 15 updated with the regular and test repos (but rawhide disabled): 1. I can reproduce the problem where Orca "welcomes" you. And then says nothing. But I cannot reproduce the hang/session-killing at this point. My system remains responsive. 2. To continue on with the bug reproduction, I logged out and back in. At this point I got a libbonobo crash. I gather Matthias did not get since Orca started working. Bonobo is of course deprecated, and Orca is expected to run using AT-SPI2. HOWEVER, in an effort to be backwards compatible for our end users, Orca checks for bonobo. If it lucks out and finds it, it will use it. Perhaps we should reverse how we do things. Ale and I shall discuss this. But anyhoo.... Given that Fedora 15 is very GNOME 3.0, I'd expect to not find bonobo. So for now I am going to assume that there's no need to pursue that particular issue (and I don't see it in other corba-based environments). However, bonobo is needed for gnome-speech, which brings me to: 3. I killed Orca and restarted it via terminal, at which point Orca went into its text-based set-up (because it never got the chance to allow user configuration in step 1, presumably because when the screen reader is enabled via the universal access panel, setup is disabled [1]). At this point I get a traceback related to gnome-speech. (An expected ACSS is a dict, which is a side effect of converting to json I believe.) This is an Orca bug that was missed because gnome-speech is deprecated and not tested like we should be testing it. I will address that bug (for backwards compatibility). But as I mentioned to Matthias via IRC, if speech-dispatcher is an option, distros are encouraged to use it instead (blessed external dependency). He pointed to this issue[2], which appears to have been addressed. I'll take care of item 3 and then keep testing.... Thanks for the report, Matthias! [1] http://git.gnome.org/browse/orca/commit/?id=5ee414ef9c88c37744ffab0ecea3c623d6545ace [2] https://bugzilla.redhat.com/show_bug.cgi?id=654585
With respect to issue #3, the gnome-speech traceback, that is now fixed via bug 646475. The fix has been committed to master. Before I beg for code freeze break from the RT, I want to dig into the other issues mentioned here (and any others I find in the process. :-) )
Matthias, with respect to the issue of the Orca not starting/hanging open launch, I kept getting gnome-speech server errors of various sorts and/or bonobo crashes. Therefore, I built speech-dispatcher, deleted my $HOME/.local/share/orca (multiple tries for testing), and now Orca is starting fine for me (with one nit) when I enable it via that UAP switch. The nit is that we on occasion pop-up a gnome-terminal window. :-/ So I'll look into that next. In the meantime, if you could pursue the speech-dispatcher-in-Fedora-15 option and let me know if this solves the startup issue for you as well, it would be awesome. Thanks! As for quitting Orca when the switch gets turned off: The proper way for a python app like Orca to do that seems to be through GSettings accessed via introspection, which means no mixing in of static bindings. So I guess this GnomeGoal [1] was a "nice-to-have" for most modules, but must-do for Orca. :-/ I'm hopeful we'll come up with a clever and safe hack/alternative over the next two days to address the reported problem for the immediate future. Then we can do it right after we tackle that GnomeGoal. [1] https://live.gnome.org/GnomeGoals/PythonIntrospectionPorting
Created attachment 185004 [details] [review] Proposed patch for the terminal window sometimes appearing issue So... At least for me.... Sometimes the terminal appears and sometimes it does not. At first I thought it was never appearing on the first switch-on, and was always appearing on subsequent switch-on's (after of course having first quit Orca and switched off). But then a few times I saw the complete opposite results. So it appears we have a timing issue of some sort. Beyond that, personally, I think the way we check if a11y is enabled needs to change. One day, hopefully, we'll never have to check at all. But today we do. And we've got GNOME 2 and GNOME 3 each doing it differently, plus Qt and XFCE a11y work underway and neither of them are using gconf or gsettings if you can imagine. ;-) I'd like to fix all of these things properly. BUT We need a safe and isolated fix and we needed it yesterday. So with apologies for making an ugly hack even uglier: This solves the problem and does so with a single, minimalistic change. Matthias, if you have the chance to try this (especially after hopefully getting a working speech-dispatcher set up in Fedora 15) it would be awesome. Please let me know what you find. For me on my Fedora 15 laptop, the only remaining issue is shutting down Orca when the switch gets turned off.
Created attachment 185078 [details] [review] Proposed patch This patch does three things: 1. Prevents Orca from popping up a terminal when the UAP screen reader switch is flipped on. 2. Causes Orca to respond to the UAP screen reader switch is flipped off. 3. Causes Orca to set the appropriate gsetting key when it is launched or quit by some other means than the UAP switch. I've been testing it with Fedora 15 with Speech Dispatcher and this patch plus not using gnome-speech *seems* to have solved all the issues Matthias and/or I observed w.r.t. this bug. <fingers crossed> My one concern is that this patch accesses gsettings via introspection. Yet Orca is not using introspection elsewhere, which means we are technically mixing the use of static bindings with introspection. It is my understanding that we should not be doing this, but I am not seeing another reasonable alternative. Therefore: I would like to meet with the other members of my team in the morning (CET time) to discuss and evaluate this patch. If we as a team agree this is the thing to do, I will present this solution to the RT for consideration for code freeze break in time for Monday's 3.0.0 release.
(In reply to comment #5) [...] > Therefore: I would like to meet with the other members of my team in the > morning (CET time) to discuss and evaluate this patch. If we as a team agree > this is the thing to do, I will present this solution to the RT for > consideration for code freeze break in time for Monday's 3.0.0 release. Ale, Javi, Juanje: Code review please. :-)
Created attachment 185082 [details] [review] Imported gtk 2.0 from gi instead of gtk I attach a patch for using Gtk 2.0 from gi instead of from gtk, so we avoid possible issues between the old and the new world. This also help let to import modules from gi after of importing gtk. We can move lower the functions and also use gi.reposiroty modules from other parts of Orca (i.e. backends/gsettings_backend.py).
I forgot to mention that the previous patch is made against to the Joanie's one.
Review of attachment 185078 [details] [review]: Seems good to me. Javier, please check the functionality and review it.
Review of attachment 185082 [details] [review]: I think that this don't hurt in our gnome-3 branch.
I applied both patches and all is fine (about this bug) in 2.91.93 world
So as I continue to test, I'm finding some apps are not accessible as expected (straightforward, accessible apps like gedit and gnome-terminal which used to work just fine in gnome 2). It looks like accessibility support is not getting enabled for the session in some cases until Orca is started. And I suspect that this might be causing some apps to be unknown to the registry and/or not emitting accessibility-related signals. We really need to address this issue (ideally for today's 3.0.0 release).
Created attachment 185127 [details] [review] proposed patch for 3.0.0 My patch combined with a patch from Javi for the settings manager (which was checking gconf keys).
Comment on attachment 185127 [details] [review] proposed patch for 3.0.0 NOTE: We did not get the required 2/2 approvals from the Release Team. Therefore this patch did NOT get committed in time for the 3.0.0 release. This commit will cause it to be included in the 3.0.1 release. http://git.gnome.org/browse/orca/commit/?h=gnome-3-0&id=dfe3dbc698a963fb4164da958a069b8e495d0b37
Couldn't be a good idea to change the gtk imports (as I suggested in my patch) so we try to avoid future issues because of mixing old and new gtk world? I mean adding this: +import gi +gi.require_version("Gtk", "2.0") And changing all the gtk imports like this: - import gtk + from gi.repository import Gtk as gtk I guess that if we are going to use gi.repository for gsettings at the Orca's core, there is not a reason for not changing 'import gtk' to 'from gi.repository import Gtk as gtk', is it? What do you think?
(In reply to comment #15) > Couldn't be a good idea to change the gtk imports (as I suggested in my patch) > so we try to avoid future issues because of mixing old and new gtk world? Maybe but what about stuff like this: http://www.mail-archive.com/pygtk@daa.com.au/msg20190.html "If you want to use gtk+-2 I suggest you stick with pygtk." http://www.mail-archive.com/pygtk@daa.com.au/msg20196.html "I would add that you should always be specific on which version you are loading. Gtk2 works under introspection but pretty much minimally." (We need more than pretty much minimally. We need works fully.) Beyond that, hopefully we'll have time now to get back to doing the gui separation work so we can (as suggested) stick with pygtk for gtk2 systems; use gi for gtk3 systems; and so on. And things won't get mixed. Beyond that, without your patch, the other patches worked. With your patch, they *seemed* to, but on multiple occasions while testing I got Fedora 15 in a screen that said something like "an error occurred from which it could not recover." It showed an unhappy faced computer and suggested I log out. After testing extensively all weekend and more today, I never saw that issue until your patch. (I fully acknowledge that could be coincidence, and might not have anything at all to do with your patch. I simply do not know. And I try to be conservative, especially this late in the cycle.) Finally, note that we didn't "reject" your patch, or close this bug or anything like that. We simply haven't concluded what to do with it. After some sleep and de-stressing, we should all talk further about it. Ok?? (And sorry!)
(In reply to comment #16) > Maybe but what about stuff like this: > > http://www.mail-archive.com/pygtk@daa.com.au/msg20190.html > "If you want to use gtk+-2 I suggest you stick with pygtk." > I saw this part, but I guessed it was more like a suggestion to avoid get to much complicated. > http://www.mail-archive.com/pygtk@daa.com.au/msg20196.html > "I would add that you should always be specific on which version you are > loading. Gtk2 works under introspection but pretty much minimally." > > (We need more than pretty much minimally. We need works fully.) > Yeah, you're probably right. I think I passed this part of the mail... > Beyond that, hopefully we'll have time now to get back to doing the gui > separation work so we can (as suggested) stick with pygtk for gtk2 systems; use > gi for gtk3 systems; and so on. And things won't get mixed. > It would be nice, indeed. > Beyond that, without your patch, the other patches worked. With your patch, > they *seemed* to, but on multiple occasions while testing I got Fedora 15 in a > screen that said something like "an error occurred from which it could not > recover." It showed an unhappy faced computer and suggested I log out. After > testing extensively all weekend and more today, I never saw that issue until > your patch. (I fully acknowledge that could be coincidence, and might not have > anything at all to do with your patch. I simply do not know. And I try to be > conservative, especially this late in the cycle.) > That's a weird bug... I guess it can be a issue because of that minimalist suport from introspection... > Finally, note that we didn't "reject" your patch, or close this bug or anything > like that. We simply haven't concluded what to do with it. After some sleep and > de-stressing, we should all talk further about it. Ok?? > Actually, I didn't care much about my patch, I was just worried for the probability of having "ghost overrides" or overlaps because those gtk imports. I was checking during the weekend the gi.overrides and it seems to miss some stuff that maybe can come up when an import get a typelib with the same name... or stuff like that. That was my concern. The patch was just a example of how to get working gsettings and gtk no matter the order of the imports. > (And sorry!) Why? I am sorry for make late noise... :-/
This bug has long ago been fixed. Not sure why it's still open.