Congratulation, promise patch, very nice future function, but little need working with this function before Orca developers committing I think:
Unfortunately I found some problems with non english language usage:
1. When I press Orca+Alt+o binding, the first spokened string is not marked translatable, and see another localize specific problem:
I hear following string if I using hungarian language:
0 Orca flatreview commands are available. They are:
This is possible happening because in Orca hungarian translation we translating keybinding descriptions the flat review word with "egyszerű áttekintés" part word, so, possible the script not found flat review commands if the language is not english.
You wonderful marking translation with two keybinding description string in learn mode, thank you.

2. When I press Orca+Shift+o, Orca wonderful spokening all keybindings, but have not marked translation words and messages.

The difficulter problem with first problem, I have not got ydea how can possible do this part with language independent, the second problem I welcome fixing if you want.

So, congratulation with your first contribution!

Attila

Review of attachment 159571 [details] [review]:

Hi,

Thank you for your patch,
This is an intresting feature, will have to see how the others feel.



some comments with regard to the code:

issue 1:

in def speakOrcaFlatReviewKeyBindings you have

if kb.handler.description.find("flat review")<>-1:

I think this might fail when people are using a diffrent language, because the word flat review in the description field would be translated.
maybe allow it to be translated as well:
if kb.handler.description.find(_("flat review")) != -1:

but this isnt a clean way, because it depends on the translators being consistent when translating flat review.

maybe there is another way of doing it?


issue 2:
A little further down you have

message = "%d orca flat review ..."
speech.speak(_(message))

it should be:

message = _("%d orca flat review ...")
speech.speak(message)

same thing for clickCount and the rest of the message.

issue 3:

put long comments before the statements that they are commenting
statement # long comment
should be:
# long comment
statement

Once again thanks for your patch and looking forward to excellent contributions.

Hy Jon,

Please wait any change the script, now I working with localization specific issues.
Flat review keybindings spokening function are done, I do Orca general keybindings spokening function now.
I localized all need marking translation need strings, now, flat review command spokening function is perfect working with hungarian language.
Because the script now default use search not marked translation flat review word when try search flat review command keybinding descriptions, I marked translation this word, and tell translation comment with translators need translate the flat review word with lovercase letters. I not have another ydea, this is perfect working with hungarian language, because flat review word translated in Orca with egyszerű áttekintés word with all flat review keybinding descriptions in hungarian language.

When I done this works, I attach the modifyed patch.

So, this function is nice work when full done!

Attila

Created attachment 159585 [details] [review]
Second revision patch, with solving localization issues and result cleaner code.

Jon, please look this second revision of this functions.
I solved all found localization specific issues, and little cleaner the original code.

Now, I tested this function with hungarian and english locale, the two functions absolute working right both two languages.
I replace the KEYPAD string with marked translated numpad string in keysims string replacement code.

If not have another issues with need doing, this function is full done, please commit with second revision patch in master branch if this is possible.

Attila

I'll leave it to Jon to review this patch, etc.

Before anything w.r.t. this bug gets committed to master, however, I would like to see what the community's feedback is. Thanks!

Created attachment 159591 [details] [review]
Third revision, fixed a traceback issue

Original code containing a wrong return line with both two functions with prewious I forgot fix, the original line is following:
     return true

This is invalid, see following traceback message from debug.out file:
Traceback (most recent call last):

+ Trace 221554

Now I fixed this problem, only need replace with true to True word both two return lines.
Now the script is full good, not producing traceback messages.

Attila

Thanks Attila,

Was wondering if the shortcut keys can be improved.

maybe something with the h key.

Will wait for some further user feedback before committing.

FWIW: A few things jump out at me about this:

1. I'm not seeing the braille output support. While I accept the fact that we may have a ways to go before we achieve speech-braille equality, I don't really like our taking a step further back with a speech-only function.

2. Rather than assign *any* shortcuts to this functionality (you may have noticed a big discussion on the list recently about what makes something keybinding-worthy), what if it were something that were activated from within learn mode. You press Insert H and Orca tells you that you're in learn mode, press any key to hear its function, press some other key to get a list of all the keybindings, or press Escape to exit.

3. There are a bunch of keybindings depending on the app you are in (for example, Firefox). So what happens if you're listening and listening and finally, command number 20 is the one you care about but the phone rings, or you cough, or whatever. Oh crap. Now it's gone and you must execute the command *again* and pay attention to 19 commands *again* and hope you catch it the next time around. It would be better if these commands could be reviewed. We already have functionality along those lines in the form of the chat history. But instead of using Orca F1 through F9, perhaps we could have right arrow present the next command and left arrow present the previous command. If you do that, and present it in both speech and in braille, I think this sort of feature would be much more usable and useful in general, and for more people.

Attila, Jon, Joanmarie

Hi! Thank you all for the time and efforts spent in evaluating and improving the initial suggestion. For a beginner like me, your comments are a source of learning and encouragement.

I am in general agreement with Joanmarie's suggestions in "FWIW: A few things jump out at me about this:". I have started work on implementing the suggestions and will post the revised patches shortly.

Joanmarie, I agree with you wroted.
Of course braille support is need, I welcome do the braille support, if following method is enough to send output in braille display:
braille.displayMessage(message)
If this is not enough, please anybody give some instructions, because unfortunately I haven't got a braille display, so I have a question:
For example, when I request flat review keybindings, Orca send 24 awailable keybindings informations, if I request Orca general keybindings and not launched another applications with have extra Orca keybindings, Orca sends 33 keybindings information. Braille users how can possible browse the sent output if we using braille.displaymessage function to display output in braille display?

Another interesting think what happening now for example when I launch Firefox and request Orca general keybindings:
Well, the second function spokening me Orca have 104 general keybindings if I launched Firefox, because I already set local the needed structural navigation keys. :-):-)
Not too long output this application dependent spokened or future braille outputted list if an application is launched? I think impossible to listen and memorize 104 key combinations with simple bigger general Orca keybindings and application dependent keybindings list with one output.
Perhaps need cutting the Orca general keybinding function spokening (and of course braille displaying) feature with two part:
1. Orca general defined keybindings spokening and braille outputting, now, this is 33 key combinations my machine.
2. Orca application dependent keybindings spokening and braille outputting with another shortcut, for example, Orca+Shift+a if have Orca application keybindings defined with a launched application.
Well, when we possible do this, the function shortcuts is following changed:
Orca+Shift+o: spokening only general Orca keybindings, but not spokening Orca application dependent keybindings. Have anybody any ydea how can possible detect absolute sure what number of general Orca keybindings have with target machine? For example, what happening if any user set an unbound keybinding, for example increase or decrease speech? Have an end mark what the last index position with general Orca keybindings list with actual user account, and what the start position beginning application defined keybindings list?

Attila

Well, I set keystrokes now following default unbound keybindings with testing purpose:
Increase speech pich: Orca+Alt+Up
Decrease speech pitch: Orca+Alt+Down
Increase speech rate: Orca+Shift+up
Decrease speech rate: Orca+Shift+Down

This change resulting of course not 33 general Orca keybindings, resulting 37 general Orca keybindings if not have a launched application with have application dependent Orca keybindings.

Attila

Created attachment 159663 [details] [review]
4. revision of this function, with containing simple braille output support.

I added simple braille support output writing with braille.displayMessage(message) method both two functions.
When I look in debug.out file what happening, I correct see the braille sent output, I don't no this is real good with phisical braille displays or not, need testing if have anybody a braille display.
I complete the learn mode messages with new braille support.

Please test this new revision,

Attila

Based on comment# 8 by Joanmarie and comment# 10 by Atilla, I visualize the following scenario. Does it sound OK?

1. Listing Orca shortcuts will be a part of learn mode.

Pressing Orca + H activates learn mode.
Orca says,
Entering learn mode. Press any key to hear its function. Press O to list basic Orca shortcuts. Press O twice to list application related Orca shortcuts. To exit learn mode, press the Escape key.

Pressing O activates list of basic Orca shortcuts.
Orca says,
Listing basic Orca shortcuts. Press Left key to hear the next shortcut. Press Right key to hear the previous shortcut. To exit the list, press the Escape key.

Pressing O twice activates list of application related Orca shortcuts.
Orca says,
Listing application related Orca shortcuts. Press Left key to hear the next shortcut. Press Right key to hear the previous shortcut. To exit the list, press the Escape key.

2. All basic Orca shortcuts (flat review and others) will be placed in one group. This group will consist of all the shortcuts defined in default.script.py

3. All application related Orca shortcuts will be placed in the other group. This group will consist of all shortcuts in the orca_state.activeScript less the shortcuts defined in default.script.py. 

Awaiting feedback, I shall start work with the above, please.

Nice ydea, I agree. If you begin do this modification, please don't forget marking translation with new added strings, and don't forget braille support with braille.displayMessage(message) if this is the right method for braille support, Joanmarie or Joe tell this.
One possible problem when we apply this functions with learn mode, Orca always spokening "right" text before the user ask next keybinding information.

Good work,

Attila

Hey all. In terms of braille.displayMessage(message), the answer is sorta. :-)

That big ol' change I asked that folks test boils down to: You should not call braille.anything. Ever. Stop it. I mean it. Really. Don't do it. <grins>

If you pull the latest from master, you will now see the following method in default.py:

    def displayBrailleMessage(message, cursor=-1, flashTime=0):
        """Displays a single line, setting the cursor to the given position,
        ensuring that the cursor is in view.

        Arguments:
        - message: the string to display
        - cursor: the 0-based cursor position, where -1 (default) means no
          cursor
        - flashTime:  if non-0, the number of milliseconds to display the
          regions before reverting back to what was there before. A 0 means
          to not do any flashing.  A negative number means to display the
          message until some other message comes along or the user presses
          a cursor routing key.
        """

All it does is turn around and call braille.displayMessage(). That's why I said "sorta" above. In other words, yes, you are correct, you need to use that functionality. But please use the default script's convenience method for doing so.

Also notice what's in the docstring for that method: flashTime (which defaults to 0) can be set to a negative number which will cause Orca to keep displaying the message until some other message comes along. This is what I think you want to do. That way, the keybinding will be displayed for as long as the user needs it (i.e. until he/she moves on to find out what the next or previous binding is). 

Also note (again, from the docstring above) that if you just call self.displayBrailleMessage(message), message will never be displayed. You have to specify a flash time if you want the message to appear, sit for a while, and then go away (i.e. to display whatever it was displaying before). If you were to do that (i.e. in some other feature; not this one), you should prefer the user setting. (i.e. flashTime=settings.brailleFlashTime)

Hope this helps.

Note that I need to bury my head in my DayJob duties for the next few days so I won't be around to answer any detailed questions on this bug until the end of the week. Sorry! If Jon is around, hopefully he can help y'all out. The only reason I chimed in here is because I was concerned about the lack of braille. I really think it's important that we are accessible to all users. And I'm very glad y'all agree. Thanks for tackling the braille!!

Created attachment 159702 [details] [review]
Fix Joanmarie wroted mistake with braille support.

Joanmarie, thank you the instructions. Prewious I not often write braille related code, I see this old method with Storm Dragon orca-customizations.py script, I am very sorry this.
Now I hope fixed this problem with following braille message writing method:
braille.displayMessage(message, 0, -1)

Of course, now this is not full optional because the keybinding messages following after by after, but if Daktatray do he wroted changes, he's function change resulting one spokened and one braille wroted keybinding information, and need the user press for example right arrow to hear next keybinding information, or left arrow if he or she would like hear prewious information. This is the optional way I think.


Note: Anybody give me a hint how can I possible test my braille output writing message real result without have a phisical braille display? Orca braille monitor feature is good this purpose if messages follow after by after?

Attila

Hi dhatdv, yes if you could implement it so that it is within help mode, that would be excellent.

Maybe it it is natural to use up/down for previous and next keybinding.
The person will be reminded of a list.


Hi Attila,

It is great that you are so happy about this enhancement, but since bhatdv has offered to do the patch for us then we should give him a chanse :)
Remember we want more people to help write good code for orca.
So lets help bhatdv by giving him good comments and test the patches that he provides.

Is there another bug that you wish to provide patches for?
I am willing to help where i can.



Thank you both for your time.

Hi All,

I have started work keeping in mind the new requirements; will keep you posted about the progress. Thanks and regards.

Jon, you are absolute right, I absolute agree your comment.
When I see this feature, I am begin very happy, and begin do patches more faster, my only purpose I would like help Daktatray, but this method not give chance Daktatray to do need fixes and learn, you are absolute right. I am sorry, I choosed wrong way to help. So, I slowest. :-):-)
I newer forgot the good feeling when I working with child position index spokening feature in Orca 2.28 development version, and Will help me introduction with this work or give me instructions, and when this feature final part of Orca.

I absolute agree need more people to contribute Orca development. I only a hobby developer, but if my knowledges is enough to fix easyest Orca bugs or do new features, I welcome help, because I always like learning and very like Orca Screen Reader, and would like help community if my knowledges is enough.

Attila

Hi All,

As promised, I am submitting a new patch, mostly as described in my comment 13 but with following deviations -
A). Since 'o' is a structural navigation shortcut for Firefox, I have used 'c' in stead of 'o' to activate the listing of shortcuts.
B). In stead of 'Left/ Right', I have used 'Up/ Down' for navigating the list, as suggested by Jon.


The working of the new feature is summarized below -
1). User presses Orca + 'h'.
Orca says, "Entering learn mode. Press any key to hear its function. Press 'c' to hear a list of Orca default shortcuts. Press 'c twice' to hear a list of Orca shortcuts for the application under under focus. To exit learn mode, press the 'Escape' key."

2). User presses 'c'.
Orca says, "68 Orca default shortcuts are listed. Use 'Up' and 'Down' keys to navigate the list; or press 'Escape' to exit.

3). User presses 'c twice' (with focus on Firefox)
Orca says, "63 Orca shortcuts for Firefox are listed. Use 'Up' and 'Down' keys to navigate the list; or press 'Escape' to exit.

4). The user can navigate the list, using 'Up/ Down' keys. If user presses 'Up/ Down' while on 'First/ Last' item, control wraps to 'Last/ First' item. Until user exits the list, keys other than 'c/ Up/ Down/ Escape' are not effective.

5). User presses 'Escape'
Orca says, "Leaving list of shortcuts."
The user gets back to the normal functioning of learn mode.


In the new patch, I have provided Braille output wherever required. But, because I have been working with Orca 2.30, I have not changed over from braille.displayMessage to default.displayBrailleMessage. I have also tried to take care of the translation issue, based on my understanding.


Though the patch is working fine, I am a little uneasy over the choice of keys (c and c double click, in learn mode). My worries about this choice are -
I). By pressing a key in learn mode, Orca just describes what the key does, or echoes the key if it does not have an assigned function. We are deviating from this principle by assigning some REAL functions to 'c/ c double click'.
II). We are using up 'c'. In future, it would not be available as a structural navigation key.
III). If tomorrow, users want commands for listing Open Office shortcuts or Gnome shortcuts to be added, what keys can we assign?

Here is a new thought. What if we assign Orca+H(double click) to activate a 'command listing' mode? Once the mode is enabled, a user -
presses 1 to hear list of Orca default shortcuts
presses 2 to hear list of Orca shortcuts for focussed application
presses 3 to hear list of focussed Application shortcuts (OO, FF etc.)
presses 4 to hear list of Gnome shortcuts 
and so on. User exits command listing mode by pressing escape. I feel this approach would address above worries.


Kindly give your feedback on the attached patch. Please also give your views on assigning Orca + H (double click) to 'command listing mode' as mentioned above.


Regards.

Created attachment 160810 [details] [review]
Patch: Commands  to hear list of Orca shortcuts.

Hi All,

As promised, I am submitting a new patch, mostly as described in my comment 13
but with following deviations -
A). Since 'o' is a structural navigation shortcut for Firefox, I have used 'c'
in stead of 'o' to activate the listing of shortcuts.
B). In stead of 'Left/ Right', I have used 'Up/ Down' for navigating the list,
as suggested by Jon.


The working of the new feature is summarized below -
1). User presses Orca + 'h'.
Orca says, "Entering learn mode. Press any key to hear its function. Press 'c'
to hear a list of Orca default shortcuts. Press 'c twice' to hear a list of
Orca shortcuts for the application under under focus. To exit learn mode, press
the 'Escape' key."

2). User presses 'c'.
Orca says, "68 Orca default shortcuts are listed. Use 'Up' and 'Down' keys to
navigate the list; or press 'Escape' to exit.

3). User presses 'c twice' (with focus on Firefox)
Orca says, "63 Orca shortcuts for Firefox are listed. Use 'Up' and 'Down' keys
to navigate the list; or press 'Escape' to exit.

4). The user can navigate the list, using 'Up/ Down' keys. If user presses 'Up/
Down' while on 'First/ Last' item, control wraps to 'Last/ First' item. Until
user exits the list, keys other than 'c/ Up/ Down/ Escape' are not effective.

5). User presses 'Escape'
Orca says, "Leaving list of shortcuts."
The user gets back to the normal functioning of learn mode.


In the new patch, I have provided Braille output wherever required. But,
because I have been working with Orca 2.30, I have not changed over from
braille.displayMessage to default.displayBrailleMessage. I have also tried to
take care of the translation issue, based on my understanding.


Though the patch is working fine, I am a little uneasy over the choice of keys
(c and c double click, in learn mode). My worries about this choice are -
I). By pressing a key in learn mode, Orca just describes what the key does, or
echoes the key if it does not have an assigned function. We are deviating from
this principle by assigning some REAL functions to 'c/ c double click'.
II). We are using up 'c'. In future, it would not be available as a structural
navigation key.
III). If tomorrow, users want commands for listing Open Office shortcuts or
Gnome shortcuts to be added, what keys can we assign?

Here is a new thought. What if we assign Orca+H(double click) to activate a
'command listing' mode? Once the mode is enabled, a user -
presses 1 to hear list of Orca default shortcuts
presses 2 to hear list of Orca shortcuts for focussed application
presses 3 to hear list of focussed Application shortcuts (OO, FF etc.)
presses 4 to hear list of Gnome shortcuts 
and so on. User exits command listing mode by pressing escape. I feel this
approach would address above worries.


Kindly give your feedback on the attached patch. Please also give your views on
assigning Orca + H (double click) to 'command listing mode' as mentioned above.


Regards.

Created attachment 160821 [details] [review]
This patch based on Daktatrai patch, but compatible with Orca git master source code.

Jon, please not angry me, but I doed now the git master branch compatible patch with based on Daktatray prewious attached brilliant patch to have a git master compatible starting point in future work. :-):-)
Please review this patch if this is possible, I not tested the braille output working, but the speech output part is full good.

Daktatray, following comment part is only learning purpose, please not angry me, but sorry my possible bad english with some sentences, anybody please complete my learning comment if are not full understable a part with english:
First,  I would like congratulation with your great work with this function development. I solved this master compatible patch with few translated related issues, and actualized little the code with git master branch. Your patch is very good, and not need lot of work to actualize the git master branch and fixing some translation related issues, see my comment below.
My first suggestion is a little technical hint in your future niceful working:
If you would like future developing a new function with need resulting new translated strings or do a complete new feature with actual stable version is not containing, please not use stable branch with coding, use Orca git master branch. The already publicated stable versions does'nt possible accept new features, does'nt possible add new marked translated strings, because stable branches are freezed, concentrating only bug fixing.
Because you based on Orca 2.30 version when coding your patch, your patch default.py part hunk#3 are failed to appli in Orca git master code.
In your patch, you use following two line with problematic in Orca git master branch code to modify present learning mode braille message:
-        braille.displayMessage(_("Learn mode.  Press escape to exit."))
+        braille.displayMessage(_("Learn mode.  Press any key to hear its function. "\
+        "Press c to hear list of shortcuts. Press escape to exit."))
The - character beginning line try to remove the original learn mode braille display message line with src/orca/default.py file, but in git master branch src/orca/default.py file not have this line, so, the hunk#3 apply is failed, newer to working with git master branch code.
The right git master branch compatible two line the patch is following:
-        self.displayBrailleMessage(_("Learn mode.  Press escape to exit."))
+        self.displayBrailleMessage(_("Learn mode.  Press any key to hear its function. "\
+        "Press c to hear list of shortcuts. Press escape to exit."))

Now, look how can you do a %d or %d %s variable translations with not working now non english locales (for example in hungarian Orca translation):
Your patch containing following original code lines with need resulting a translated message with containing a variable value in non english locales, but this messages is newer working right with non english locale and resulting english language string output with a non english locale:
+            message = _("%d Orca default shortcuts are listed. Use Up & Down keys \
+            to navigate the list; or press Escape to exit." % numShortcuts)
Unfortunately you put a wrong place the right paren character, the right working code is following:
+            message = _("%d Orca default shortcuts are listed. Use Up & Down keys \
+            to navigate the list; or press Escape to exit.") % numShortcuts
If I not replaced your this type code lines with the right sintax, the marked this type translated messages are putted with a non english language Orca translation .po file if the translators do intltool-update language command, but this wrong code generated translated messages is not working if the right paren character is not proper placed.
What happening if you need pass more variables with a marked translation message?
For example now the problem is similar in your patch with following message code line:
+                message = _("%d Orca %s shortcuts are listed. Use Up & Down \
+                keys to navigate the list; or press Escape to exit." % \
+                (numShortcuts, orca_state.activeScript.app.name))
This code line newer resulting right proper not english locale translated message, the right code line is following:
+                message = _("%d Orca %s shortcuts are listed. Use Up & Down \
+                keys to navigate the list; or press Escape to exit.") % \
+                (numShortcuts, orca_state.activeScript.app.name)
Because you need now this situation pass more variables the generated translated message, first need close a right paren character the real translated message, and need put the real variables after the % character with left paren and close the variable list with right paren.

Attila

(In reply to comment #21)
> Hi All,
> 
> As promised, I am submitting a new patch, mostly as described in my comment 13
> but with following deviations -
> A). Since 'o' is a structural navigation shortcut for Firefox, I have used 'c'
> in stead of 'o' to activate the listing of shortcuts.
> B). In stead of 'Left/ Right', I have used 'Up/ Down' for navigating the list,
> as suggested by Jon.
 
Thanks for doing this :)

[...]
> 
> 4). The user can navigate the list, using 'Up/ Down' keys. If user presses 'Up/
> Down' while on 'First/ Last' item, control wraps to 'Last/ First' item. Until
> user exits the list, keys other than 'c/ Up/ Down/ Escape' are not effective.

Glad to see that the user gets a message when they wrap around. :)

> 5). User presses 'Escape'
> Orca says, "Leaving list of shortcuts."
> The user gets back to the normal functioning of learn mode.
> 
> 
> In the new patch, I have provided Braille output wherever required. But,
> because I have been working with Orca 2.30, I have not changed over from
> braille.displayMessage to default.displayBrailleMessage. I have also tried to
> take care of the translation issue, based on my understanding.

as Atilla points out, Development should be against master branch, other branches are for bug fixes, and enhancements would rarely be pushed back.

[...]
> Here is a new thought. What if we assign Orca+H(double click) to activate a
> 'command listing' mode? Once the mode is enabled, a user -
> presses 1 to hear list of Orca default shortcuts
> presses 2 to hear list of Orca shortcuts for focussed application
> presses 3 to hear list of focussed Application shortcuts (OO, FF etc.)
> presses 4 to hear list of Gnome shortcuts 
> and so on. User exits command listing mode by pressing escape. I feel this
> approach would address above worries.

Your idea sounds good.
1 and 2 are orca related so it is easy, but not so sure if 3 and 4 can be done, i dont think there is a way for us to ask an application to give us a list of all its shortcuts, or ask gnome for all system wide shortcuts, but i might be wrong.
If you get 1 and 2 done, you can then have a look if 3 and 4 are feasible

Further to the things that attilla mensioned:
long strings should be written like this:
message = _("this is a really " \
  "long message")

and in the case of messages with arguments:
(Atilla is this correct?)

message = _("%d this is "
"a message with two arguments %d.") % (arg1, arg2)

Thanks again for your excellent work.

sorry i ment.

and in the case of messages with arguments:
(Atilla is this correct?)

message = _("%d this is " \
  "a message with two arguments %d.") % (arg1, arg2)


Also please make sure that the new code doesnt have lines longer than 80 chars.

Thanks.

Hy Jon,

Yes, I think your last putted two parameter translated message code is correct, but I need verify. Daktatray use \ separator in code I think because the message code generation line is too long to fit with one line, but this is not do problem with final translated message output with translation files.
What can happening the braille output if have a longer message to generated, for example the braille outputted learn mode message? only braille user with not using Orca speech support how can possible read this longer message with a 20 cell or 40 cell braille display if first going to default learn mode? Or this message presenting braille display the default setted flash time and the braille user possible to scroll the learning mode message in braille display?

Atilla, Jon

Thank you very much for clearly explaining the message formatting and the other useful principles. I will submit a revised patch soon, against the master branch, and using the Orca + H(double click) binding.

Regards.

Daktatray, please little wait, because I now working with wordwrapping my master compatible patch, I think this is easyest your starting work in Git master, because not need you recode your all code. In src/orca.py patch part is done now, I changed the message format with John suggested format, and I fixed a prewious forgotted translation issue when the user go to the keyboard shortcut list and press for example the left CTRL key. Because prewious the right paren is wrong place, this situation not generated the translated message correctly, now this is fixed.
Jon, following code is full correct, and very nice wordwrap the final generated translated message in translation file when the translators do intltool-update language command if Daktatray final patch is committed to git master:
            message = _("%d Orca shortcuts are listed. Use Up & Down keys "
            "to navigate the list; or press Escape to exit.") % numShortcuts
Another example with more passed parameters:
                message = _("%d Orca %s shortcuts are listed. Use Up & Down "
                "keys to navigate the list; or press Escape to exit.") % \
                (numShortcuts, orca_state.activeScript.app.name)

Daktatray, just a moment, I attaching my actual patch, please use this patch with starting point when you begin working the final revision, because all translation related issues is fixed now.

Attila

Created attachment 160886 [details] [review]
Second git master branch compatible patch with based on Daktatray attached last patch

Daktatray, here the second git master compatible patch.
Please use this patch to starting point when you coding in git master, because all translation related typical problems are fixed now with this revision.
In src/orca/orca.py code lines is full wordwrapped with maximum 80 characters, but another code lines is not (for example in src/orca/default.py).

Good work,

Attila

Created attachment 161178 [details] [review]
Revised patch; adds 'list shortcuts' mode; created against master branvh.

Hi Jon, Atilla

Here is the revised patch, created against the master branch, and taking care of the formatting issues which you have kindly explained in your comments.

As discussed with Jon in comment#23, I have added a 'list shortcuts' mode, which can be enabled by pressing Orca + H (double click). In this mode, the user can list Orca default shortcuts by pressing 1 and Orca shortcuts for the application under focus by pressing 2. After selecting one of the two lists, the user can navigate and hear the shortcuts with Up/ Down keys, can toggle between the lists by pressing 1 or 2, or can exit the 'list shortcuts' mode by pressing Escape.

Kindly give your feedback on the attached patch. If you find this OK, I would try adding two more commands to 'list shortcuts' mode, viz. Listing the Application (OO, FF etc.) shortcuts by pressing 3; and listing the Gnome shortcuts by pressing 4.

Thanks again for your kind encouragement and guidance.

Dattatray, I tested your patch. You do great and careful work, I not found any translation related issues, your patch generated outputs are full localizable.
Speech part functions is works perfect without mistakes, unfortunately I unable to test the braille output mode.
So, great job.

Unfortunately I haven't got any full useful ydea how can possible add FF and OO keybindings with this feature with 3 keybinding command without need you manual add the application depending keybindings with a localizable list, this is same true with GNOME keybindings. But, possible Jon or Joanie have a more experience ydea how can possible implementing this without language depending and easy implementing way.
For example, in GNOME key bindings, possible easy to look GNOME keybindings depending g-conf keybindings command names and key bindings, but this is possible not an elegant method always read g-conf keys, replace a human readable format and send the output with one by one. This implementation way resulting you extra work of coding.
Another problem with this implementation method, some keybindings stored in apps/gnome_settings_daemon/keybindings g-conf directory, but some key bindings are not, stored with different g-conf places. I think this is not good implementation ydea, but possible Jon or Joanie have better implementation ydea with this future purpose feature part.

Attila

Hi Jon,

Have you seen the revised patch (comment#29) please? Attila tested the patch (except Braille output) and found it OK. I have checked Braille output on Orca's Braille monitor. If I need to do anything further, please let me know.

Regards.

Hi, very sorry for the delay.

It will be the first thing i will look at tomorrow.

Created attachment 161765 [details] [review]
Fix for bgo#616820 - There is no command to speak the list of available Orca keyboard shortcuts.

Hi DVBhat,

Good news, this looks good to go now.
I modified your patch to provide translation messages wherever we have 
messages to be translated.
Also pylinted code to 10.0

I am committing this to master on your behalf.

Just a small reminder
git config --global user.name 'D V Bhat' 
and 
git config --global user.email 'email addr'

If you could email the mailing list and tell them that this feature is now 
available in master, and we can see what their feedback is.

Thanks again for your good work, and looking forward to working with you 
to solve more issues.

You can change the status of this bug as resolved/fixed. (it will slowly 
give you more and more bugzilla points *smiling* )

-Jon

Jon, thanks the master commit, works fine the committed version.
I think now need change this bug status to resolved fixed status. Unfortunately I have not right possibility to change the status.
Dattatray, I would like you congratulation with this feature, and wish you nice work in future. You do a very great and useful function with Orca for new beginner users.

Thank you your work,

Attila

Thanks for doing this guys!

Jon: On enterListShortcutsMode() there is a separate braille prompt and speech prompt and they are nearly identical, but not quite. That means double work for the translators. Is there any reason the string you're using for braille cannot be used for speech?

Thanks!

Jon: In orca.py I see that you've imported default and are calling it. That means the active script cannot handle this functionality. Instead, please remove your import and use orca_state.activeScript to make the call.

Thanks!

Oops, sorry, caught another mistake in orca.py:

use presentMessage() instead of making separate calls to speech.speak() and displayMessage().

Thanks Joanie, will do.

Awesome thanks!

Please let me know when you've done so. Because I'm not entirely happy with the dialog box changes I'm making for the flash messages, I'll want that to get some testing and feedback from you and others before I commit them. So I'm pushing the dialog changes to the start of 2.31.3. Your changes for this bug are what I'm waiting on to do the 2.31.2 release.

I just did some additional nit and string clean-up.

In particular:

* Undid a couple of the activeScript changes Jon made. It turns out that you need them to obtain the default shortcuts. One resulted in a traceback. When that was fixed, the app-specfic shortcuts still didn't work (because they need to come from the default script). However, you do not need -- and specifically you do not want -- to use default.Script when you're making calls to things like displayBraille() and presentMessage(). You really want those to be the methods from orca_state.activeScript. Otherwise, you're short-circuiting a script's ability to override the default behavior.

* Moved the import of default in orca.py to the one and only method that uses it. While import something huge when most of the time the user doesn't need it?

* Removed the tab characters. (Why were those there??) While we don't yet have a spatial mode for braille (i.e. displaying 4 or 8 or whatever characters instead of a single tab char), one day we will. And when we do, having a Tab character here might make things look strange (and force the user to pan the braille display unnecessarily). When I used a space character instead of a Tab, things still looked right to me on my braille display, and they were spoken correctly. If there's something I'm missing which makes having a Tab character essential here, please let me know and we can reconsider restoring it.

* Re-used strings. We already say "Wrapping to top" and "Wrapping to bottom" elsewhere (structural navigation, flat review find). Users seem to know what those mean. I don't see why we need to have a slightly different -- and tad more verbose -- version for lists, nor do I see value in making additional work for our very dear, hard-working translators who already have a bazillion strings to translate in Orca.

* Similar to the above, there were places where there were two entirely separate strings where the difference is one announced the mode and then the keys you could press, and one didn't announce the mode (presumably because the user was already in that mode and you didn't want to repeat it). Rather than give the translators two big ol' strings to translate, why not break these apart?

* Tested the changes and the new feature in general. It seems to be working.