GNOME Bugzilla – Bug 558497
Values in the global Orca Preferences dialog are based on the active script
Last modified: 2014-05-19 04:05:22 UTC
Steps to reproduce: 1. Launch Orca and Firefox. 2. Press Orca+Space 3. Examine the tree of text attributes Expected results: The text attributes listed would reflect the generic, Orca-wide text attribute list. Actual results: The text attributes listed reflect those associated with Gecko (i.e. the active script) Proposed solution: Move allTextAttributes out of settings.py and into default.py or script.py.
Created attachment 127557 [details] [review] revision 1 Okay, this is admittedly a hack. The problem is that the active script remains that of the application until after the dialog is loaded. (i.e. the deactivate methods in scripts are called too late). The easiest/most minimal change seems to be to force the active script to be the default script before we get and use the prefsDict (aka settings). That's what this patch does. It pylints and seems to work just fine with both Orca-wide prefs and app-specific prefs. Will, whatcha think? Thanks!
(In reply to comment #1) > Will, whatcha think? Thanks! I'm seeing some strangeness. I tried this: 1) Run orca, give gnome-terminal focus. 2) Insert+space, change default key echo settings, then hit "OK". 3) Ctrl+Insert+space, change gnome-terminal key echo settings then hit "OK". 4) Insert+space, look at default key echo settings. 5) Ctrl+Insert+space, look at gnome-terminal key echo settings. For some reason, I'm not seeing the settings end up being what I set them to. They actually end up looking kind of odd and I can't figure out a pattern to it.
Thanks for finding that Will. I see the same thing. And I see it with the patch and without it. I'll investigate further. In the meantime, could you please see if the patch has any impact on what you're describing? Thanks!
(In reply to comment #3) > Thanks for finding that Will. I see the same thing. And I see it with the patch > and without it. I'll investigate further. I took a look at it some more, and I think what we're seeing might be a side effect of the design where the app-specific preferences only reflect was what different from the default preferences at the time the app-specific preferences were created. Something still seems strange, though, and I haven't figured it out. > In the meantime, could you please see > if the patch has any impact on what you're describing? Thanks! I'm not sure if it effects it. I kind of want to get a better understanding of what's going on, though, before checking this patch in. The thing we're seeing may be another symptom of the underlying thing behind this bug, but I'm not sure. In addition, the patch really is kind of a nasty hack in that it creates a new instance of the focus tracking presenter, which really is meant to be a singleton. It might be better to move the logic to orca.py:showPreferencesGUI since the orca.py module has a handle to the existing focus tracking presenter. But then again, I'm seeing some sort of stuff in app_gui_prefs.py that also violates the singleton model. So, I think we need a better understanding of what the heck is going on overall. Another thing to think about, btw, is whether we're doing a deep copy of structures or not. That is, when we copy a settings value that is a dictionary, for example, are we just copying a pointer to the dictionary or are we making a complete copy of the dictionary?
Just a quick executive summary: the current way that global settings and app-specific settings are handled is a bit touchy/brittle. The main reason for this is that the original design never accounted for app-specific settings and we ended up kind of hacking to retrofit the code for app-specific settings. We're going to delay work on this bug until we do the refactor, which is tracked via bug #570650.
Hopefully this will fixed as a side effect of the Settings work being done.