Braille settings: Sort output/input braille tables list

[josephsl]

Hi,

Currently, output/input braille tables list shows the list of braille tables based on the order found in braille.TABLES tuple. Although it allows one to reassign braille tables via a simple index operations, it might be more desirable to allow users to go through all tables in sorted order (for example, going from English to French as opposed to English and then Spanish).

To achieve this, a new dictionary named "tables" will be used to replace two lists, with the key being the name of the table and value being filenames. For example, BrailleSettingsDialog.tables["English (U.S.) grade 1"] points to "en-us-g1.ctb".

Surrounding implementations:

1. When loading table names, sort tables.keys.
2. For OK button handler, look up table names.GetStringSelection and assign the value found for this key.
3. If this is working for output tables, input tables presentation will be modified accordingly.

Possible issues/questions:

• How about non-English locales? We can take advantage of the fact that Python is aware of Unicode, hence one can sort using this.
• Is current approach acceptable? When one wishes to look at tables loaded with no regard to ordering, yes, as current method displays table names in the order they are declared in the braille module. The sorting part is handy if one wishes to browse through tables in a sorted order, similar to list of braille displays and synthesizers.
• GetStringSelection versus GetSelection: GetStringSelection is better in that we can use it as the key to the dictionary. Using GetSelection means looking up the string once more based on its index.

Thanks.

[LeonarddeR]

I remember @Dkager has made major changes to the way braille
  table references are stored in #3304. There's also a needs code
  review on #3304 which I think might be good to finish before
  working on this.
@Dkager: your thoughts?

[josephsl]

A specific variant on #3304, addressed by @dkager in one of the external branches (depends on #2439). Thanks.

[jcsteh]

Reopening this, as it will get addressed as part of #6449 (but I still think it's worth tracking separately).