GNOME Bugzilla – Bug 353151
When started for the first time under X, Orca should use gui-setup by default.
Last modified: 2008-07-22 19:24:04 UTC
Please describe the problem: When Orca is started for the first time under X, it is using the text based setup. in this instance, it should make use of the GUI instead. Steps to reproduce: From within X, run Orca from a fresh user account, or delete your user-settings.py Actual results: Orca is running the text based setup. Expected results: The GUI based setup should come up at this point. Does this happen every time? yes Other information:
I cannot reproduce this bug. The designed behavior for which flavor of the setup presented to the user is as follows: 0) The text setup will be used if the user explicity requests it with --text-setup or -t. 1) If accessibility is not enabled for the session, the text setup is run. The reason for this is that the GUI will essentially be inaccessible since accessibility is not enabled. So, we give the user something they can access, assuming they run orca from a terminal. If orca can detect that it is not being run from a terminal, it probably should show the GUI and try to do *something*, I guess. 2) If Orca cannot open the X Window System display, or it cannot successfully import the Python gtk module (often means the X server isn't available), the text setup is run. The reason for this is that Orca will be unable to present the GUI. 3) In all other cases (e.g., the X Window System is available and accessibility is enabled for the session), the GUI setup is run. In any case, I tried deleting my ~/.orca/user-settings.py and then re-running Orca. I wasn't able to reproduce the behavior you are reporting. :-( So...I have a few questions for you: How are you launching Orca? If you're doing it from a terminal window, does an X Window System utility such as "xdpyinfo" work? If not, your shell cannot access the X server. What does 'gconftool-2 --get /desktop/gnome/interface/accessibility' return? If it returns 'false', accessibility is not enabled.
Hi Will, Sorry, maybe i'm just confused. I was under the impression that there was already a GUI for situations where accessibility had not yet been enabled. Maybe just close this out, or make it an RFE? --Al
Hi Al. There is a logout dialog GUI. It's even in the Glade file. The problem is there isn't a Python binding to the routine that we need to call to effect the logout. See bug #340849 for more details.
(In reply to comment #2) > Hi Will, > > Sorry, maybe i'm just confused. I was under the impression that there was > already a GUI for situations where accessibility had not yet been enabled. > Maybe just close this out, or make it an RFE? > > --Al I think we need to decide upon just what the desired behavior here is. I'm guessing that one would want the following: no matter how Orca is launched for the first time, one wants the setup to be accessible. The current implementation and support of the AT-SPI on the GNOME platform puts a little wrinkle in this: accessibility is not enabled by default, so it needs to be enabled and the user needs to log out and log back in in order to provide access to any GUI. If GNOME shipped with accessibility enabled by default, life would be much easier. We currently rely on accessibility to be enabled for the session to provide an accessible configuration GUI for Orca. I suppose we could make it self-voicing, but I think that might add a fair amount of complexity to the code. Right now, Orca tries to reduce the number of steps you need to go through to get Orca going, with the goal being that the enabling of accessibility and the configuring of Orca is done in one step. We see that this fails miserably when the text-based setup ends up getting run via a GUI process (i.e., there's no console for you to enter your answers). I'm curious if the following might be a reasonable workaround: when Orca is run and it detects that accessibility it not enabled, it sets the magic gconf accessibility setting. It also speaks and brailles if possible and pops up a GUI, all of which tell you that accessibility has just been enabled and you need to log out and log back in (when we get access to the API for logging out, we'll make the log out step part of this process). No configuration of Orca is done until you log out, log back in, and rerun Orca. This is a little bit clunky, but it resolves the confusing case where users don't realize they need to log out and log back in in order for accessibility to be enabled. However, this still doesn't explain the experience you had when you reported the bug. I'm not sure exactly what was happening there. Is it that you didn't log out and log back in in order to enable accessibility for your session? Finally, at the GNOME Boston Accessibility Summit in October, I hope that we will be able to define a bigger picture for the choice, initialization, and setup of assistive technologies across the board. We all realize that it needs a fair amount of work now that we're in the lucky situation of having a number of assistive technologies to choose from.
*** Bug 354167 has been marked as a duplicate of this bug. ***
The current behavior of Orca v1.0.0 is to bring up a gnome-terminal if the user will be placed in text-setup mode. The goal here is to provide a means for the Orca to have an accessible "first run" no matter what the current system configuration is. I think we're pretty close with what we've got. Al - is the Orca v1.0.0 behavior sufficient for you?
Yes, this currently behaves sensibly and is indeed sufficient. Thanks.
Thanks Al. Closing as Fixed.