GNOME Bugzilla – Bug 522980
Orca should handle startup where "import pyatspi" fails
Last modified: 2008-04-27 20:33:03 UTC
Steps to reproduce: From http://mail.gnome.org/archives/orca-list/2008-March/msg00397.html: This appears to have changed recently. If I run it without setting the DISPLAY environment variable to point to an X display, I get: jason jdc:~$ orca -t /var/lib/python-support/python2.4/gtk-2.0/gtk/__init__.py:72: GtkWarning: could not open display warnings.warn(str(e), _gtk.Warning) Traceback (most recent call last):
+ Trace 192692
import pyatspi
reg = bonobo.activation.activate_from_id(REGISTRY_IID, 0, 0) Bonobo.GeneralError
To prevent the crash, we might try treating "import pyatspi" problems similar to how we treat "import gtk" problems, and we might also need to do some additional handling in orca.main(). Not sure, but I wanted to make sure this was logged as a known problem.
Even if I export DISPLAY=:0 from a separate virtual console and run orca -t while the X server is running, a backtrace result (see attachment). As this appears to be coming from Gnome-speech, it may be a separate bug.
Created attachment 107492 [details] Session log showing backtraces.
(In reply to comment #1) > Even if I export DISPLAY=:0 from a separate virtual console and run orca -t > while the X server is running, a backtrace result (see attachment). > > As this appears to be coming from Gnome-speech, it may be a separate bug. > This appears to be a separate problem where gnome-speech might not be functioning properly (or no gnome-speech drivers are available).
Note that the backtraces occur even if --disable=speech is specified on the command line. In general, I don't think Orca should be importing Gnome speech, GTK, Pyatspi, etc., when text setup is selected. All it needs to do is write prompts to the terminal and read user input. It doesn't even need (or use) ncurses.
(In reply to comment #4) > Note that the backtraces occur even if --disable=speech is specified on the > command line. Thank you. I opened bug 523082 to track this.
(In reply to comment #0) > Steps to reproduce: I'm also able to reproduce this by doing an "su - orca" where "orca" is my test user and then making sure no X server is available to that user (it may actually be that no DBUS session is running as well, but I'm not sure). If I then run the following command, I get the error: -bash-3.2$ python -c "import pyatspi" Traceback (most recent call last):
+ Trace 194064
In looking into how to fix this, it's going to be a quagmire. The pyatspi module is imported all over the place. As such, I'm curious if we might consider modifying pyatspi to postpone the activation of the registry to the call to registry.start(). Eitan, what are your thoughts on that?
This is not a bad idea...
(In reply to comment #6) > In looking into how to fix this, it's going to be a quagmire. The pyatspi > module is imported all over the place. On second thought.. Why would this be a quagmire? Just like the trace above shows, this is raised in orca.py. Can't we catch it there and give proper output? Yeah, it would need some reshuffling of a bit of code in orca.py. My concern is that since this bug is considered "critical", I don't think it would be right to require users to have the latest version of pyatspi.
(In reply to comment #8) > (In reply to comment #6) > > In looking into how to fix this, it's going to be a quagmire. The pyatspi > > module is imported all over the place. > > On second thought.. Why would this be a quagmire? Just like the trace above > shows, this is raised in orca.py. Can't we catch it there and give proper > output? > > Yeah, it would need some reshuffling of a bit of code in orca.py. It would need quite a bit of reshuffling of nearly every import in orca.py because those imports end up importing pyatspi, or things they import end up importing pyatspi. Even debug.py imports it. :-(
(In reply to comment #8) > My concern is that since this bug is considered "critical", I don't think it > would be right to require users to have the latest version of pyatspi. Agreed. I'm wondering if we should knock this bug down in terms of priorty/severity. I think it tends to occur when someone is attempting to run Orca in a situation where it's impossible to run Orca, and is doing so under non-standard configurations. So...I'm thinking it still might be nice to try to delay the activation of the registry until the start() call. What do you think, Eitan?
Please don't lower the priority of this bug. It prevents users from configuring Orca in the text console before first login.
Perhaps a function could be written that performs the import and handles any exception, returning False on failure, which the caller could test for (or not) as desired. The problem is that we would then be effectively ignoring the exception. If pyatspi can't be imported for some other reason (e.g., an installation problem) then it won't be detected until an attempt is made to access pyatspi.something later on. If a solution along these lines were adopted, it should be easy to perform a global search and replace across all the source files to replace, for example import pyatspi with protected_import("pyatspi") Nevertheless, I don't much like the idea of ignoring import errors, even though I know this is already done elsewhere for the gtk module.
The patch in bug 529611 suppresses exceptions at import time of pyatspi. RuntimeError is raised when registry operations occur. This includes registering event listeners, which we do in orca.py before we start the registry.
Latest pyatspi (and orca) should have this fixed. Anybody waht to verify before I close this?
I just tested with Orca revision 3848 and pyatspi revision 1010. Orca -t now works from the console as expected.
Thanks Kenny for reporting back! This bug is fixed with orca and pyatspi trunk combined.