Am 07.04.2009 um 08:45 schrieb Matthew Talbert:
The fact remains that old locale files and new locale files cannot
operate
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
do
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
same
sword configuration. I can't see how passing hard coded paths is a
better
solution.
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();
lManager->loadConfigDir([localePath UTF8String]);
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.
Manfred
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
