[sword-devel] Sword for BPBible 1.5.12
bergmannmd at web.de
Tue Apr 7 01:09:23 MST 2009
Am 07.04.2009 um 08:45 schrieb Matthew Talbert:
>> The fact remains that old locale files and new locale files cannot
>> on the same sword configuration. Both 1.5.x and 1.6.x will fail if
>> this is
>> the case. We can make 1.6.x ignore the 1.5.x locales, but we can't
>> anything about the 1.5.x software already on the computer. It will
>> cease to
>> work. The correct thing to do is to not mix locale formats on the
>> sword configuration. I can't see how passing hard coded paths is a
> This bothers me as well. I don't have a solution, but I know that it
> is impossible for us to know during installation where the user's
> locales.d actually is. I'm thinking in particular of users that
> specify SWORD_PATH as being somewhere other than the default. If we
> can't tell for sure where they are during installation, then we can't
> overwrite or remove the old ones, so we really don't have control over
> what is going to happen when the user starts up the front-end. As I
> said, I don't really have a solution, but it would seem that locales.d
> should be handled a little differently than SWORD_PATH. Specifying a
> path for LocaleMgr would probably work, though I haven't really
> thought about it.
We're specifying a path for LocalMgr in MacSword in form of:
sword::LocaleMgr *lManager = sword::LocaleMgr::getSystemLocaleMgr();
We have to since Mac OSX doesn't have a package management system as
part of the OS.
So we can't and won't tell the user to install (or even compile) the
Sword library as a dependency for MacSword.
That's why we deliver the complete library including locales.d within
the Application bundle.
More information about the sword-devel