Hello, Yes I agree this seems to be solving the wrong thing.Also would a "for the short term" API change then be removed later? If so then that could break applications and to leave it in would just lead to more API calls available than needed (a cluttered API).
I don't know how this sounds for an idea: * Have a liblouis function available for list available tables* Have a separate function call or set of function calls for querying a given table for user-friendly information.
This then could be done in two stages, the first soon and the other later when how to present the information has been worked out.
Michael Whapples On 21/06/2012 09:13, Christian Egli wrote:
Mesar Hameed <mesar.hameed@xxxxxxxxx> writes:On Thu 21/06/12,08:41, Christian Egli wrote:Mesar Hameed <mesar.hameed@xxxxxxxxx> writes:Orca/NVDA/any other program needs to know what tables are available, so that they can be presented in a nice/user friendly combobox for the user to select from.OK, that makes perfect sense. But then you don't really want to know the PATH to the tables. Instead you want to know the tables, i.e. the tables that you as an Orca user can use. So no dis tables, no include tables, etc. And all of this of course with a nice (translatable) name. This seems to come back to the age old discussion of the mapping between iso language code, grade, number_of_dots and liblouis table file. Maybe we should offer an API to query this instead.Yes exactly, this is the plan, but it would be good to provide something in the meantime, while we sort out what/how exactly things should be done.The problem if we provide an (half-baked) API "for the meantime" is that we will be stuck with this API. I'd rather not have any API changes before 2.6, i.e. not for this release but in the next. Thanks Christian
For a description of the software, to download it and links to project pages go to http://www.abilitiessoft.com
