GNOME Bugzilla – Bug 372273
Add ability to configure app-specific settings via GUI
Last modified: 2007-05-03 16:23:45 UTC
In response to http://bugzilla.gnome.org/show_bug.cgi?id=363815, we now have the ability to have application-specific settings. (Thanks Rich!) It would be helpful if we could configure these settings via GUI rather than having to manually edit files within ~/.orca/app-settings.
*** Bug 400708 has been marked as a duplicate of this bug. ***
Just a thought on this front: *Potentially* one might want to customize most of what is currently in the Orca preferences dialog on an app-by-app basis. Therefore, what about: * Using Insert/CapsLock + Shift + Space to get into a preferences dialog for the application with focus. * The application preferences dialog would essentially be the Orca preferences dialog with a different window title and irrelevant items grayed out (e.g. I don't think showing the Orca main window is relevant to application-specific settings)
I agree withh this idea in general How about the following? CTRL+orca+space will bring up a window to configure the settings for the current application. This is currently bound to reload settings which will have to move This window will look similar to the default orca prefs dialog but will be missing the general tab. The settings that get saved will contain only those that are different from the default. It would be ideal if this app specific file could also contain any persistant watched objects or bookmarked objects for the current application or document.
As I commented here: http://bugzilla.gnome.org/show_bug.cgi?id=319659#c4 When we're looking at the keybindings tree, we should be sure to list the app-specific keybindings at the top so that users can quickly find them.
I've been starting to think about this. I have some questions and a comment: Q1. If we are going to use Ctrl+Orca+space for this, and moving the "reload settings" option, what keybind are we moving it to? C1. Rather than do a delta of the generic Orca preferences as originally thought, I believe we are going to have to save all the settings each time. Nnot only to make it easier to code, but to potentially make it remain correct if the user tweaks the generic settings after doing some app. specific settings. Q2. My plan was just "blow away" ~/.orca/app-settings/<app name>.py each time the user updated the app specific setting for <app name>. Do we want want them to have the abilty to have some app specific settings that won't get blown away? Maybe look for a "<app name>-customizations.py file in the ~/.orca/app-settings directory and read that, in a similar way to what we do with "orca-customizations" in the ~/.orca directory with user-settings.py? Q3. Comment #4 mentions putting the app-specific keybindings at the top so the user can quickly find them. How can I determine what they are? Do I need to add something extra in that tells me this? Q4. What are the preference items that are irrelevant, and should be grayed out for app-specific settings? Thanks.
Answers after discussion in this weeks Orca team meeting. A1. Just lose the existing use of Ctrl+Orca+Space ("reload settings"). C1. Will do delta of differences from the generic settings. A2. Will implement the suggested approach in Q2 in comment #5. A3. Don't know how to do this yet. Will leave out of the first attempt at a patch for app specific settings. A4. All the settings on the General tab and Speech factory and server on the speech tab, should be grayed out.
Rich, do you need anything more from me at this point?
On this bug no. I do need you to comment on bug #400716 though.
And it looks like you just did. Thanks!
Created attachment 86868 [details] [review] First cut at a patch to implement most of this functionality. Here's a first cut at a patch to implement the GUI for application-specific preferences in Orca. I have *NOT* committed it yet. I'd like feedback from the Orca team before I do that. Changes made: Adjusted <ORCA MODIFIER>+Control+Space to now bring up the application specific preferences dialog. The previous usage (reload user settings) is now gone. The application specific preferences dialog does not have a general pane and the Speech systems and servers controls on the speech tab are grayed out. Application specific settings are written to ~/.orca/app-settings/<APPNAME>.py Only the differences from the generic Orca user preferences are written out. If you want to have application specific customizations that won't get overridden, then these need to be saved in ~/.orca/app-settings/<APPNAME>-customizations.py There is a new file called app_prefs.py. I'm not convinced that "svn diff" was smart enough to do the right thing here, so in order to test this patch I think you are going to have to: % cd /path/to/where/you/have/orca/trunk % touch src/orca/app_prefs.py % patch -p0 < ~/Desktop/patch-372273.txt (or whereever you saved the patch). % ./autogen.sh --prefix=/usr % make % sudo make install Key bindings are a still-to-do item. I currently have no clue what's needed here. Still investigating. This does give you something to test though.
Just getting started on testing this. Try the following: 1. Launch Orca 2. Move focus to Application X and press Control Insert Space 3. In the resulting Application X specific dialog make a change (I switched punctuation from some to most) 4. Press the OK button. 5. Move focus to Application Y and press Control Insert Space You'll get a dialog box for Application X 6. Press Escape and try again You'll get a small empty window for Application Y I've tried this test with combinations of OOo Writer, Firefox, Gedit, Gnome-terminal, and Evolution.
Mike phone to say he's seeing a similar thing (sans the results of step 6). I'm investigating now. Thanks.
Created attachment 86885 [details] [review] Revised version of the patch based on feedback from Mike and Joanie. This obsoletes the previous patch. This hopefully fixes up the problems you were both seeing. If it doesn't, please let me know. I'll start looking at the changes needed to handle key bindings tomorrow. (Patch not committed yet).
Much better. It now seems to be bringing up settings for the correct application. thanks
> Much better. It now seems to be bringing up settings for the correct > application. Confirmed. Something occurred to me -- and I am going to guess at Rich's answer before I share what that thing is: "Please file a separate RFE" ;-) Still, I figured I'd comment here first. :-) What, if anything, do we want to do about app-UNIQUE settings? For instance, in Gaim there is a setting to preface chatroom messages with the name of the chatroom. Similarly, there is a setting in Gecko.py to toggle who is controlling the caret (and there will eventually be one to toggle whether or not structural navigation keys should be used, and likely other settings to come...). In Evolution we have a setting to toggle whether we present new mail if we are not the active script. When we get more script contributions from the community we may see further app-UNIQUE settings still. I'm envisioning an additional page in the app-specific settings dialog in which app-UNIQUE settings are listed and able to be configured. I am also NOT envisioning this as high -- or even medium -- priority. Again, merely tossing it out there for consideration....
>> Much better. It now seems to be bringing up settings for the correct >> application. > Confirmed. Okay, thanks. I'll commit this patch in a few minutes, then carry on working on the key bindings. > What, if anything, do we want to do about app-UNIQUE settings? For instance, > in Gaim there is a setting to preface chatroom messages with the name of the > chatroom. Similarly, there is a setting in Gecko.py to toggle who is > controlling the caret (and there will eventually be one to toggle whether or > not structural navigation keys should be used, and likely other settings to > come...). In Evolution we have a setting to toggle whether we present new mail > if we are not the active script. When we get more script contributions from > the community we may see further app-UNIQUE settings still. This I see as being the same problem as app-specific keyboard bindings. How do we know what they are? I'd like Will to comment on this when he's back from vacation, but my thoughts here is we are going to have to define a WellKnown variable (or two), that we can look for in the script's __dict__. If it exists, it will contain the information we need. > I'm envisioning an additional page in the app-specific settings dialog in which > app-UNIQUE settings are listed and able to be configured. I am also NOT > envisioning this as high -- or even medium -- priority. Again, merely tossing > it out there for consideration.... Yup, that would be a good way to show them. As Will and I previously discussed, you would have to know how to cons up the GUI for properly displaying each option (checkbox, radio buttons, text field...). It's not a simple problem. It certainly deserves a lot more thought, and yes, let's open up another enhancement request for all of this. The only thing left I want to fix for this bug is the key bindings.
Patch committed. I'm going to start looking at the key binding stuff now.
For the sake of connecting all the dots, the new RFE regarding app-unique settings is bug #433146.
With all the recent work on bug #433146, this bug is now being moved into the "[pending]" state.
I think this feature is working really well. I know Rich wants to fix one other thing related to keybindings getting loaded without reloading the application settings but when he is happy I'd say close this one.
I'm going to close out this one. The final known problem is being discussed in the other bug (bug #433146), so I'll use that for it. Any other app-specific setting problems found by the community can fire off new bugs.