[bt-devel] BibleCS / BibleTime on Windows

[Troy A. Griffitts]

Eeli,

After looking at the dialog you posted, I revisited the code we changed 
in SWMgr to help the Xiphos guys on their Windows port.  I had forgotten 
that we added OS specific lookup paths at the end of the lookup algorithm.

For Windows:
$ALLUSERSPROFILE/Application Data/sword/mods.d/

For Mac OSX:
$HOME/Library/Application Support/Sword/

I'll add these to the INSTALL doc.

The core history behind the lookup logic is such that:
Originally, SWORD just wanted to find a single path for modules: DataPath
Then we added the idea of augmenting personal modules to the primary 
DataPath: ~/.sword
Then to support mobile devices with flash memory, we added AugmentPath.

Generally, a user installation isn't much more complicated than this.

There are many other smaller variations added for other needs over the 
years, but this is the basic history.  The primary goal of the lookup 
has always been to find the primary DataPath.  Hence, when sword.conf's 
DataPath is invalid, we don't use the .conf file.  I'm not opposed to 
changing this logic.  If there is a real need, I hope you know that want 
to help your team.  Would you suggest that if sword.conf doesn't contain 
DataPath, then the default lookup algorithm continues on to try to find 
one?  And after that lookup attempt, the sword.conf AugmentPath entries 
are applied?  This sounds reasonable and shouldn't affect adversely any 
existing configurations.  sword.conf skipping if DataPath is invalid 
currently is a misconfiguration anyway; if we change this logic, we 
would just be changing the way we handle existing misconfigurations.

Troy


Eeli Kaikkonen wrote:
> On Fri, 12 Feb 2010, Gary Holmlund wrote:
> 
>> This seems reasonable. I believe it all of it except the on/off of the
>> private path is possible just using the sword.conf file. I have not had
>> a chance to look at SWMgr in detail. Was the change you had in mind for
>> SWMgr related to controlling all of the paths? Does it have any other
>> advantages?
> 
> The backend (=swmgr) is so complicated that when I found a new problem I
> have forgotten an older one. I think I had a reason to not use
> sword.conf at all. One might be that if the DataPath doesn't have a
> valid path (one with existing mods.d/ dir) the whole file isn't used at
> all. This is stupid IMO but that's how the default system works.
> Therefore we should either write complicated code to put a path with
> mods.d/ always in DataPath or not use sword.conf at all. I also feel
> that it's not useful at all to use ~/.sword/sword.conf because other
> applications don't use it, and if they use, we might mess things up for
> them, because they could use it differently. There just doesn't exist a
> way to configure the paths freely AND co-operate with other frontends at
> the same time.
> 
>> I have also been working on the MDI toolbars. This turned into a bigger
>> task that I originally thought, but I am about 75% done on it. I am
>> thinking I should finish this first.
> 
> We are not in time for 2.6 anyways. I tried to design the first-time
> module installation helper screen but couldn't figure out a decent logic
> for the use cases, UI and code. I'm still trying to do it for 2.7.
> Otherwise I could continue with this task. Let's see how it goes.
> 
>   Yours,
> 	Eeli Kaikkonen (Mr.), Oulu, Finland
> 	e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)
> 
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel