I fear I cannot dig down into these issues now. But I would hope that ctypes allows to hard-code a path for the dll, say, relative to the louis package root which works cross platforms. And the tables dir could be assumed there, too, by default. So if the user does not specify a path in the function call, the package dir/tables path is used. In this context, a Louis class could come in handy with some methods for translation, back translation etc. whereby the path, tables etc. are set upon instantiation. But this would clearly require significant changes to the bindings. Also I haven't looked at the new bindings yet so please don't blame me for misunderstanding things.
Leo Am 14.11.2010 22:03, schrieb James Teh:
On 14/11/2010 8:08 PM, Dr.Leo wrote:This is one of the reasons we distribute them separately in the 3rdParty dir on our site. The theory is that if there was a reasonable way to distribute them officially, that archive would be removed.I remember having taken the .dll I have been using until now from an older NVDA release. But it is very wierd to do this given that the Python bindings belong to liblouis and are valuable even without NVDA.There's no instantiation, but you can specify the path to each function you call (i.e. specify it explicitly). However, the *default* table path is specified at compile time. In short, on Windows, you always have to specify a path explicitly unless you build your own dll.It appears that the Python bindings allow to specify the table path at instantiation time.The dll search path is a Windows thing, not a Python thing. You can manipulate it by changing the PATH environment variable or using Windows functions. However, this still doesn't solve the problem of where to put it.I am unaware of an easy way to specify a .dll path in the bindings' setup.py. But it should be worth checking if somewhere in the Python os module or ctypes there isn't an environment varible pointing to the standard .dll dirs.Not possible. The sources need to be configured using autotools and the like. Also, distributing both source and binaries in the same package is very unconventional.So it might be possible to ship a Python package with the C sources and the windows dll whereby the windows dll is installed if the platform fits, and the C sources are compiled otherwise.There's nowhere specific to copy either of these. The dll has to be somewhere in the dll search path (which could include the directory from which the application was launched, which is what we do for NVDA). As noted above, the default tables directory is useless on Windows because people might want to put it somewhere else or might have a different system configuration.So I guess at a minimum, there should be a zip file for download from googlecode containing the latest Python bindings plus instructions on where to get the latest dll and where to copy it manually and where to copy the tables etc.Jamie
For a description of the software, to download it and links to project pages go to http://www.abilitiessoft.com
