I've been thinking about this a bit today.

Here's what I'm leaning to (still half baked):

There would be a new method (probably in script.py rather than
default.py) called getAppPreferencesGUI() (or some such name).
The default implementation would just return None.

Application scripts that had their own unique application-specific
settings would provide their own implementation of this method.
What I'm thinking at the moment (and it still needs to be fully
thought out and probably prototyped) is that the method, when
implemented, would return a GtkVBox. Within that GtkVBox would be
all the GUI needed to shown those unique settings and allow the user
to twiddle them. All the callbacks hooked up to those widgets would 
have to be defined too.

In app_gui_prefs.py, the code that puts together the application
specific GUI would call <script>.getAppPreferencesGUI(). If it
returned something other than None, it would create a new tab in the
notebook (looking for a good name for that tab - feel free to comment)
and add it in (on the rightmost end), and wedge that GtkVBox in it.

Hitting the Apply/OK button on the app-specific configuration dialog
would automatically write out these settings too. Maybe we'll need 
another method for this as well. Dunno just yet.

This is still a work in progress. It needs more investigation. More later.

Hey Rich.  This is already sounding VERY cool!!

Regarding this:

> Application scripts that had their own unique application-specific
> settings would provide their own implementation of this method 
> What I'm thinking at the moment (and it still needs to be fully
> thought out and probably prototyped) is that the method, when
> implemented, would return a GtkVBox.

<brainstorming title="Feel free to ignore/shoot down :-)">
How would this GtkVBox be created, designed, etc.?  Would there be any expectation of the script-writer being able to spatially arrange the controls?  How do we ensure there are no resulting HIG violations? :-) Are we in danger of no two application pages in the settings dialog looking alike, having the same keyboard shortcuts, etc.? 

*Assuming I am following you*.... As long as it's the Orca team doing the scripting and GtkVBox creation, these are non-issues.  But it is my hope -- and my expectation -- that as the community continues to grow, we'll begin to see an influx of more community-generated and/or modified scripts.  From this perspective.... We might be able to enforce some quality control/uniformity, while at the same time making it easier to contribute scripts with unique settings, if we do not expect the script to return a GtkVBox.  :-) 

So what do we do then?  

<more brainstorming>
Maybe the script could return the settings themselves???  For each setting we might want:

* SettingName (the actual setting name in the script, e.g. "controlCaretNavigation")

* PrintableName (what we expose to the user as the setting name, e.g. "Caret Navigation Control")

* Description (more details we provide to the user, e.g. "Gecko native caret navigation is where Firefox itself controls how the arrow keys move the caret around HTML content. We have found that this is not always reliable.  Therefore you may prefer to have Orca control the caret instead.")

* PossibleOptions (a list of tuples, maybe??)

  In each tuple:

    * ActualValue from the script perspective (e.g. "True")

    * Description (what we expose to the user, e.g. "Orca")

From this we could generate the GtkVBox:

* Row 1:  A tree of all of the settings.  Each item in the tree would be a PrintableName

* Row 2:  The Description associated with the selected item in the tree from Row 1

* Row 3:  The "twiddling" bit.  I'm thinking a combo box:  for each PossibleOption, display the Description; store the ActualValue.

The user could then arrow to the setting in Row 1 that he/she cared about, Tab to Row 2 to read what the heck it was, and if it needed changing, Tab to Row 3 to twiddle.  
</more brainstorming>
</brainstorming>

Thoughts?

Created attachment 86998 [details] [review]
Patch to implement this for the gaim script.

The best way to show how this would work is with an example:

Here's what this patch (not committed yet because I suspect
that Will will suggest a different approach) does:

          Added two new methods to the Script class:
              def getAppPreferencesGUI(self):
              Returns a GtkVBox contain the application unique configuration
              GUI items for the current application.

              def writeAppPreferences(self, prefs):
              Write out the application specific preferences lines.

          Any application that has application unique settings need to
          overridge those methods any implement them.

          If <script>.getAppPreferencesGUI() does return something other
          than None (the default), then that is assumed to be a Gtk widget
          that can be given to a new tab in the application configuration
          dialog.

          Adjusted the gaim script to do exactly that. What this does seem
          to mean is that those settings values need to be global variables
          within the application script file rather than script variables
          (self.<whatever>).

Let me know what you think of this approach.

Note that application unique key bindings should go at the top
of the key binding tab for the configuration dialog and not on this
new pane. That's the last part of bug #372273.
I still haven't worked out how to do that yet though.

> The best way to show how this would work is with an example:

Yup that makes a big difference in my understanding.  Thanks!!

That doesn't look too painful for the would-be script writer, which was my chief concern.  And I suppose it would be painful for us to figure out a way to generate the vbox given a list of settings, so nevermind on my previous comment. :-)

Okay, cool. Thanks for checking it out.
So which scripts have application unique settings (not key bindings)?

I suspose that StarOffice.py does with:

        settings.enabledTextAttributes = "size:; family-name:; weight:400; indent:0; left-margin:0; right-margin:0; underline:none; strikethrough:false; justification:left; style:normal;"

I just I'll just stuff that in a text field. 
I'll work on a patch for that next.

What others?

Regarding StarOffice and font settings: Is this relevant to  bug 372965 -- and for that matter bug 363827? In other words, is this page the place where we will (eventually) include all of the different attributes that are now exposed and allowing the user to choose which ones they want to hear when they press Orca_Modifier+F?

> What others?

Gecko.py.  Right now it's just one.  But there will be more.... :-) 

Okay. I'll knock that one out as well. So I see that we should have a checkbox
for controlCaretNavigation. What about arrowToLineBeginning? Any others? ...

Thanks.

I see you commented:
"AND add 4 app-unique table settings!" in bug #422924.
I'll hold off on doing the app prefs GUI for Gecko.py
until you have finished tweaking it. 8-)

StarOffice.py coming up (hopefully later this morning).

> Okay. I'll knock that one out as well. So I see that we should have a checkbox
> for controlCaretNavigation. What about arrowToLineBeginning? Any others? ...

Oh yeah, forgot about arrowToLineBeginning.  Sorry about that.

As I commented on in bug #422924, there will be -- assuming Mike doesn't have any objections.  

I was about to suggest that if you started the Gecko.py one, I'd patch the rest in.  But then I got a "new mail" ding with your response to the comment I just made. :-)  Holding off will work too. :-)  Thanks!

Created attachment 87071 [details] [review]
Patch adjusted to include the StarOffice unique app setting as well.

Created attachment 87085 [details] [review]
Patch further adjusted to include Gecko support as well.

Here's a first cut at this. Things to potentially change:

1/ The wording of the labels for the six checkboxes on the Firefox
   application unique tab. They might be a bit wordy at the moment.
2/ The order in which they should appear.

Lemme know.

Thanks.

I just tried it and it's not updating the settings.  I checked skipBlankLines and unchecked speakCellCoordinates and pressed the Ok button.  There was no difference in behavior in Orca, so I returned to the dialog and found that the default settings were loaded again.

As for the naming:  Could we group them somehow?  If we had a "table" or "table navigation" group, then you could have:

Speak cell coordinates
Speak multiple cell spans
Announce cell headers
Skip blank cells

and the to-be-created Ignore layout tables

Use Orca Caret Navigation, Position cursor at...., and the to-be-created Enable structural navigation could go into a group together as well.

> I just tried it and it's not updating the settings.  I checked 
> skipBlankLines and unchecked speakCellCoordinates and pressed 
> the Ok button.  There was no difference in behavior in Orca, so 
> I returned to the dialog and found that the default settings were 
> loaded again.

I think I see the problem (and it's generic across all the application
unique settings) in that I'm writing out the new values to
~/.orca/app-settings/<SCRIPT>.py, but I'm not changing them in the
running instance of the program. I'll adjust this. To confirm this, 
after setting them can you just quit Orca and restart it, and tell 
me if it's picking up the settings correctly then.

> As for the naming:  Could we group them somehow?  If we had a 
> "table" or "table navigation" group, then you could have:
> 
> Speak cell coordinates
> Speak multiple cell spans
> Announce cell headers
> Skip blank cells

I think you mean a frame, not a table don't you? Like with Magnifier
Zoomer Settings.

Okay, why don't you and Mike nut this out and then let me know what you've
decided and I'll adjust accordingly. In the meantime. I'll generate a new
patch to fix up the other problem.

Thanks.

> running instance of the program. I'll adjust this. To confirm this, 
> after setting them can you just quit Orca and restart it, and tell 
> me if it's picking up the settings correctly then.

confirmed.

> I think you mean a frame, not a table don't you? Like with Magnifier
> Zoomer Settings.

I think I mean a panel, actually.  But, yeah, like with Zoomer Settings.  :-)  But whatever the heck it is, it would be CALLED "table" (or "table navigation").  It wouldn't BE a table. :-) :-)

The 4 settings I mentioned only apply to tables (as in html tables) navigation.  Maybe down the road we'll have a panel/groupy-thing called "heading" (or "heading navigation") that would give the user the ability to turn the speaking of levels on or off.  (Not suggesting this Mike, merely an example).

> Okay, why don't you and Mike nut this out and then let me know what you've
> decided and I'll adjust accordingly. 

Okay, how 'bout the panel/whatever is called "Table Navigation" and we have another one called "General" or "General Navigation" or "Page Navigation." General/whatever would come first.  We use these table navigation labels:

Speak cell coordinates
Speak multiple cell spans
Announce cell headers
Skip blank cells

For the general ones, I'm fine with "Use Orca Caret Navigation."  The "position cursor ..." bit is a bit long, but I cannot come up with anything better that still conveys the meaning that (I think) should be conveyed.

> 
> Okay, how 'bout the panel/whatever is called "Table Navigation" and we have
> another one called "General" or "General Navigation" or "Page Navigation."
How about page navigation?

> General/whatever would come first.  We use these table navigation labels:
> 
> Speak cell coordinates
> Speak multiple cell spans
> Announce cell headers
> Skip blank cells
>
These all sound good to me. 
> For the general ones, I'm fine with "Use Orca Caret Navigation."  The "position
> cursor ..." bit is a bit long, but I cannot come up with anything better that
> still conveys the meaning that (I think) should be conveyed.
I agree
> 

Created attachment 87097 [details] [review]
Revised patch incorporating Gecko.py changes.

Patch makes the following additional changes:

1/ Updates the new app unique settings for the running application.
2/ Adjusts the Firefox/Gecko GUI per Joanie's last comments.

I think we are getting close now. Please let me know what other
tweaks you'd like.

Thanks.

Okay, I see Mike wants "Page Navigation" not "Table Navigation".
I can make that change. Let's find out what other tweaks might 
be needed before I do that.

Thanks.

I assume Mike wants "Page Navigation" instead of "General" (???)

(In reply to comment #18)
> I assume Mike wants "Page Navigation" instead of "General" (???)
> 

(In reply to comment #18)
> I assume Mike wants "Page Navigation" instead of "General" (???)
You got it.  
> 

I was thinking that it would really be nicer if the app specific page were the first one instead of the last.  I can see as we add more app specific features that the user will want to get to these most often 

Rich, I think this is awesome!!!  

The one thing that I might want to see added are mnemonics.  Some day we're going to have URL-unique scripts (and presumably settings).  However in the meantime, I can see a user accessing one table and wanting one set of options and then navigating to a table on some other page and wanting an entirely different set of options, so the ability to quickly change these would be helpful.  

Right now you can Control Insert Space, followed by End  to quickly jump to the app-unique settings.  The addition of mnemonics could get switching these down to a matter of seconds for experienced users.

Again, very cool! (And thanks for doing it)

Okay, to sum up:

1/ "Page Navigation instead of "General Navigation". No problem.

2/ Mike wants the app-unique tab to be first. No problem.

3/ Joanie would like some mnemonics. Sure. Just tell me what you'd like.

I'll make these changes tomorrow.

Thanks.

How about:

o - Use Orca Caret Navigation
p - Position cursor at start of line when navigating vertically
c - Speak cell coordinates
s - Speak multiple cell spans
h - announce cell header
b - skip blank cells

?

Thanks!

Sounds good. Thanks. More tomorrow.

There are two other changes I need to make:

1/ Change writeAppPreferences() to setAppPreferences() now that it
   also needs to change the running state. This also gives us a
   matching pair of routines.

2/ Add in label for/labelled by relationships for the GtkLabel and
   GtkEntry widgets in the StarOffice.py script.

More tomorrow.

Created attachment 87153 [details] [review]
Further revised patch.

It makes the following changes:

1/ "Page Navigation instead of "General Navigation" on the Gecko.py
    app-unique settings tab.

2/ Added mnemonics for each of the checkboxes on the Gecko.py
   app-unique settings tab.

3/ Change writeAppPreferences() to setAppPreferences() now that it
   also needs to change the running state.

4/ Add in label for relationship for the GtkLabel and
   GtkEntry widgets in the StarOffice.py script.

The only one I haven't been able to successfully do is:

5/ Put the app-unique settings tab first. 

It has problems when I try that (see output below).
As the app-unique tab is only one keystroke away
(End) once the app settings dialog is displayed, I'm
going to leave that one.

Let me know if that's okay Mike and/or if you want other
tweaks. You to Joanie.

Thanks.

--

Error output:

/usr/lib/python2.5/site-packages/orca/atspi.py:861: Warning: g_object_unref: assertion `G_IS_OBJECT (object)' failed
  accParent = self.accessible.parent
/usr/lib/python2.5/site-packages/orca/atspi.py:987: Warning: g_object_unref: assertion `G_IS_OBJECT (object)' failed
  stateSet = self.accessible.getState()
BRAILLE LINE:  'orca Application Orca Preferences for soffice.bin Dialog'
     VISIBLE:  'Orca Preferences for soffice.bin', cursor=1

+ Trace 130919

When I press the OK button after having made some changes, I get this error:

Traceback (most recent call last):

+ Trace 130943

Created attachment 87161 [details] [review]
Fixed patch (hopefully).

Sorry about that. This version of the patch should hopefully fix that problem.

Yup, sure does.  Thanks!

I just noticed one other thing, but it's one of those goofy Gecko.py things:   If you make any changes in that dialog so that the settings get reloaded, you lose your current caret context.

Try this:

1. Click somewhere in this page to get a visible caret on some text (like on the like that says "sorry about that).  If clicking doesn't give you a caret, press F7 to enable caret browsing.

2. Get into the app-specific settings dialog and press Cancel.  Arrow around.  You should be in the text you were in before.

3. Get into the app-specific settings dialog and press OK.  Arrow around.  Nothing will happen.  locusOfFocus is now the document frame.

If you know (or suspect) exactly what the problem is, I'll leave this one to you.  Otherwise, let me see what I can figure out.

This only happens if Orca is controlling the caret.  If Gecko is controlling the caret, we resume where we left off.  Presumably reloading the settings is blowing away our caretContext.  Therefore, could we store it before reloading the settings?

Ya know....

This is not an issue in what you've done Rich.  If I just get into the regular Orca Preferences dialog and press OK, I lose my caret context.  Sounds like a new and different bug to me. :-)

Glad I could help. 

I'm working on adding in support for the app-specific key bindings.
In theory it shouldn't be part of this bug, but I need some of
the code changes to make it work, so the next version of the patch 
should have this in. Well, at least the stuffing of said key bindings 
into the front of the key binding list. I'm still not sure how to save 
them yet. I'll leave that for another time. 

More in a little while.

> Glad I could help. 

Me too! ;-)

I just filed bug # 433951 on the issue of losing the caretContext.

Created attachment 87166 [details] [review]
Add in showing the app specific key bindings.

These now get displayed at the top of the key bindings list.

I think the only thing left to do is work out how to save the
modified application specific key bindings.

This feature is looking really nice.  When you get the saving of key bindings figured out the community is really going to love this.    

Created attachment 87284 [details] [review]
Add in the Gecko Structural Navigation checkbox.

Adds in another checkbox on the Firefox/Gecko app-unique
preferences pane for Orca Structural Navigation.

 Just tested it.  Thanks for adding it in Rich!

Created attachment 87341 [details] [review]
Further work on getting/setting/updating app specific key bindings.

Includes in suggestions from Will (thanks!) on how to save the
application specific key bindings. 

It appears to be writing them out to the <APPNAME>.py file under
the app-settings directory.

It appears to be correctly updating the list in the key bindings
pane on the app-specific preferences dialog correctly.

When Orca first restarts, it's appears to be reading them into the
list in the key bindings pane on the app-specific preferences 
dialog correctly

What doesn't appear to be happening still is that the new key binding
is set correctly to actually do the required action.

I'm currently stumped on that one, but I'll keep looking.

(I've modified this patch 10 times to try to keep up with SVN head.
Any chance I can check in in to cut down on the amount of work I
need to do just to keep this current?)

Thanks.

Okay, I think I've found the problem:

In loadAppSettings():

    self._knownAppSettings[name].overrideAppKeyBindings( \
                            script, script.getKeyBindings())

should have been:

 script.keyBindings = self._knownAppSettings[name].overrideAppKeyBindings( \
                            script, script.keyBindings)

Generating a new patch now and I'm going to check it in.
We can them adjust/fixup anything that's still broken.

More in a few minutes.

Created attachment 87344 [details] [review]
Hopefully a working patch.

I *think* the app-specific key bindings are working now.
I've committed the patch to make it easier for folks to try.
I'm not going to put it in a "[pending]" state until I've
had some reassurance from others that it's doing the right 
thing.

Have at it!

Thanks.

I get the message "starting Orca preferences for <appname>, this may take a while" but the dialog doesn't appear. 

Traceback (most recent call last):

+ Trace 131727

Created attachment 87349 [details] [review]
Patch to fix the latest traceback.

Needed to define a "skeleton"
def overrideAppKeyBindings(self, script, keyBindings) routine
to prevent a traceback if there were no custom key bindings
found.

Joanie then followed up with the following comment:

"That fixes the problem of the dialog not appearing.  The keybindings
don't seem to be sticking however.  I'm trying to change 1 into 0 (so
that 0 moves you to the next heading at level 1)."

I'll look into this soon.

Looks like my last changes doesn't fix the problem.
The except: part of the clause is getting closed. I guess
if you say "pass", then the exception propgates up the chain? ...

                    try:
                        script.overrideAppKeyBindings = \
                            self._knownAppSettings[name].overrideAppKeyBindings
                        script.keyBindings = \
                         self._knownAppSettings[name].overrideAppKeyBindings( \
                            script, script.keyBindings)
                    except:
                        debug.printException(debug.LEVEL_SEVERE)
                        pass

                    break

Need to investigate further...

s/closed/called/

Rich, I restarted Orca and the keybinding had taken.  It just didn't take right away. :-)

I just confirmed this with Evolution, changing Orca+n to Orca+a and then back again.  Each time the change took after restarting Orca.  And no errors.

Created attachment 87362 [details] [review]
Further fix for the previos error.

Also needed to check in loadAppSettings if the specified
module name has an "overrideAppKeyBindings" attribute.

Apparently the except: clause was getting called, but the traceback
was still being thown. I seem to remember somebody telling me you
shouldn't have "empty" except: clauses with Python 2.5. You needed
to specify an exception type (like AttributeError).

Anyhoo, I used hasattr() instead to test for the existing of the
"overrideAppKeyBindings" attribute.

So it looks like the only remaining problem is seeing why the new
key binding isn't being picked up in the running Orca application.

Created attachment 87390 [details] [review]
Patch to fix three remaining problems.

With help from Will (many thanks!) we've hopefully knocked off
the last three problems for this bug:

          1/ In loadAppsettings() in focus_tracking_presenter.py, there
             was a bogus space in a call to self._knownAppSettings.has_key().

          2/ In _writeAppPreferencesPostamble() in orca_prefs.py, the import
             line that was written out for the <APPNAME>-customizations
             file needed to have an initial "app-settings.".

          3/ In writeUserPreferences() in app_gui_prefs.py, we needed to
             call the loadAppsettings() method in FocusTrackingPresenter to
             get the new key bindings to kick in for the currently running
             application.

I've checked those changes into SVN HEAD. I'm going to move this bug
to "[pending]" state (and the other bug for app-settings GUI).

Please give it a good thrashing.

Thanks!

Thrashing away. :-)

It seems like the first time you change it the change takes immediately, but subsequent changes you still have restart Orca.  Here's what I did:

1. Started "clean" by removing my ~/.orca/app-settings directory from previous testing.

2. Launched Orca and Evolution.

3. With Evolution focused, pressed Control Insert Space, changed the new mail presentation notification to Insert+A, pressed OK.

4. Verified that it took immediately by using it and also viewing the Evolution keybindings again.

5. Quit Orca, relaunched it, reverified.  So far so good.

6. Changed it back to Insert+N.

7. Went to verify that it took immediately. It hadn't.   It was still bound to Insert+A.

8. Quit Orca and relaunched it.  It was bound to Insert+N.

Another data point:  It seems that the presence of an existing file in ~/.orca/app-settings is somehow related.  As another test, I changed the Gecko-unique setting related to caret position when navigating by line and left keybindings alone.  I quit Orca, relaunched it, and then changed the command to move to the next heading at level 1 to "0".  It didn't take until I quit and restarted Orca.

It's interesting. When Will and I were working on this, earlier
this morning, I couldn't get the new key bindings to immediately
take effect unless I Alt-Tabbed away from that application, then
Alt-Tabbed back again. For Will, it just worked.

A couple differences are that I'm using a 64bit AMD machine and
I don't have click-to-type focus mode set. I believe Will has a
32bit machine and click-to-type focus mode. As the latter in the
most normal mode for blind users, we didn't worry too much.

Does Alt-Tabbing away and back work for you? If you do that, 
does the new key binding take affect without restarting Orca?

> It's interesting. When Will and I were working on this, earlier
> this morning, I couldn't get the new key bindings to immediately
> take effect unless I Alt-Tabbed away from that application, then
> Alt-Tabbed back again. For Will, it just worked.

Did Will already have an existing app-settings though?  Did you?  The reason in comment #49 I chose to start "clean" is because things weren't taking.  I figured it might be a side effect of a remnant from an earlier patch.  Now I'm not so sure.  It would be interesting to see what happens if, having already created some app-settings for a given app, he gave it another go for that same app.  As I mentioned in comment #50, it seems that once an app has a file in app-settings, it doesn't take immediately.

> Does Alt-Tabbing away and back work for you? If you do that, 
> does the new key binding take affect without restarting Orca?

Interestingly enough, yup!  

It turns out that it is also sufficient to leave focus in the app in question, return to the app-specific dialog and immediately press Escape to leave it and once again give focus to the app in question.

This is on a 32-bit install of Feisty with all of the standard settings.

Please see the comment for bug 372273     

Created attachment 87743 [details] [review]
Patch to fix problem with app-specific key bindings.

New app-specific keybindings are now automatically working (once they've
been set), without having to Alt-Tab away and back or reloading Orca.

I think we are almost there. Putting the bug into "[pending]" state.

Will, as part of our debug work on this last problem earlier today,
you created an __str__() function for the KeyBindings class.

Could you check that in please (or let me know what you wrote and 
I'll check it in ;-).

(We might want to open up another "minor" enhancement request
to add __str__() functions for several other Orca classes. If 
that's a good idea, lemme know and I'll file it.)

Thanks.

> Will, as part of our debug work on this last problem earlier today,
> you created an __str__() function for the KeyBindings class.

Done.  :-)

> (We might want to open up another "minor" enhancement request
> to add __str__() functions for several other Orca classes. If 
> that's a good idea, lemme know and I'll file it.)

Let's just do them as needed and check them in as part of other bugs.

This feature seems to be working nicely.  It might now be OK to close.  

Okay. Thanks Mike. Closing as FIXED. If we find any more
problems related to this feature, we can open up new individual
bugs for each one.