After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 372273 - Add ability to configure app-specific settings via GUI
Add ability to configure app-specific settings via GUI
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
unspecified
Other All
: Normal enhancement
: FUTURE
Assigned To: Rich Burridge
Orca Maintainers
: 400708 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-11-08 00:33 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2007-05-03 16:23 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
First cut at a patch to implement most of this functionality. (18.28 KB, patch)
2007-04-23 18:16 UTC, Rich Burridge
none Details | Review
Revised version of the patch based on feedback from Mike and Joanie. (20.15 KB, patch)
2007-04-23 23:38 UTC, Rich Burridge
committed Details | Review

Description Joanmarie Diggs (IRC: joanie) 2006-11-08 00:33:20 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.
Comment 1 Rich Burridge 2007-01-25 21:47:22 UTC
*** Bug 400708 has been marked as a duplicate of this bug. ***
Comment 2 Joanmarie Diggs (IRC: joanie) 2007-01-28 19:38:12 UTC
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)
Comment 3 Mike Pedersen 2007-03-27 04:19:23 UTC
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.   
Comment 4 Joanmarie Diggs (IRC: joanie) 2007-03-27 16:02:04 UTC
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.
Comment 5 Rich Burridge 2007-04-02 15:18:22 UTC
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.

Comment 6 Rich Burridge 2007-04-03 19:52:34 UTC
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.
Comment 7 Mike Pedersen 2007-04-13 17:10:18 UTC
Rich, do you need anything more from me at this point?
Comment 8 Rich Burridge 2007-04-13 17:25:58 UTC
On this bug no. I do need you to comment on bug #400716 though.
Comment 9 Rich Burridge 2007-04-13 17:26:33 UTC
And it looks like you just did. Thanks!
Comment 10 Rich Burridge 2007-04-23 18:16:34 UTC
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.
Comment 11 Joanmarie Diggs (IRC: joanie) 2007-04-23 22:04:20 UTC
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.
Comment 12 Rich Burridge 2007-04-23 22:11:54 UTC
Mike phone to say he's seeing a similar thing (sans the results of step 6).
I'm investigating now.

Thanks.
Comment 13 Rich Burridge 2007-04-23 23:38:51 UTC
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).
Comment 14 Mike Pedersen 2007-04-23 23:57:45 UTC
Much better.  It now seems to be bringing up settings for the correct application. 
thanks
Comment 15 Joanmarie Diggs (IRC: joanie) 2007-04-24 07:14:57 UTC
> 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....
Comment 16 Rich Burridge 2007-04-24 15:19:23 UTC
>> 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.
Comment 17 Rich Burridge 2007-04-24 15:38:08 UTC
Patch committed. I'm going to start looking at the key binding stuff now.
Comment 18 Joanmarie Diggs (IRC: joanie) 2007-04-24 23:55:31 UTC
For the sake of connecting all the dots, the new RFE regarding app-unique settings is bug #433146.
Comment 19 Rich Burridge 2007-05-02 14:55:06 UTC
With all the recent work on bug #433146, this bug is now being
moved into the "[pending]" state.
Comment 20 Mike Pedersen 2007-05-03 15:37:01 UTC
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.  
Comment 21 Rich Burridge 2007-05-03 16:23:45 UTC
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.