[sword-devel] SwordReader

Barry Drake b.drake at ntlworld.com
Tue Nov 27 02:04:04 MST 2007


Hi Robin ..........

RLRANDALLX at aol.com wrote:
> Believe it or not I have been getting the x86Rel version to work on 
> the emulator.  It looks like if sword.conf is not at the root, you 
> can't specify your own directories.
Congratulations!!  Sorry about the sword.conf misunderstanding.  The 
logic behind the Sword engine's file finding is fully set out in INSTALL 
in the sword svn.  FYI I've copied it here:
                      
DETAILS
The API attempts to hunts down its primary module configuration in the 
following sequence, stopping at the first successful step:

    o) ./sword.conf in the format:

            [Install]
            DataPath=/where/your/modules/are/installed

        then the API will look for <DataPath>/mods.d/

    o) ./mods.d
    o) ../library/mods.d (don't ask)
    o) $SWORD_PATH/mods.d
    o) $HOME/.sword/sword.conf in the format:

            [Install]
            DataPath=/where/your/modules/are/installed

        then the API will look for <DataPath>/mods.d/

    o) /etc/sword.conf in the format:

            [Install]
            DataPath=/where/your/modules/are/installed

        then the API will look for <DataPath>/mods.d/

    o) $HOME/.sword/mods.d/

In addition to the 'primary module configuration', SWORD will also 
include modules found in $HOME/.sword/mods.d/  Also, when a sword.conf 
file is used, any number of:

AugmentDataPath=/where/more/modules/are/installed
entries may be included.  These are useful to tell sword to scan, for 
example, CDROM, MMC, or other removable media locations.

END of data from INSTALL file

What I did in swordce.cpp was to amend the getWorkingDirectory() 
function to find the directory in which sword.dll and the .exe file is 
installed.  It will now look in this directory (the Sword home 
directory) for the directories and files in the order given in the 
above.  This makes SwordReader work just like any other Sword frontend.  
You might note from the INSTALL file that the sword.conf that Johan 
wrote had an error - he had written AugmentPath=/Storage Card and it 
should have read AugmentDataPath=/Storage Card  This is why when I first 
encountered the binaries, I had a difficult time finding out how they 
were meant to work!

Since I have now taken out the hard coded static const char *cwd = 
"\\Program Files\\sword"; from swordce.cpp, there is no longer the need 
to have anything at all in a directory of that name!  Currently, I have 
the new emulator pointed to a temporary directory which it displays as a 
'Storage Card'.  In this directory is a directory called 'sword' 
containing sword.dll and simplegui.exe (renamed to SwordReader.exe) and 
also mods.d and modules directories containing the kjv bible.  There is 
no sword.conf and no need for a sword.conf any more unless you really 
want to change the way things work.  This is the configuration that I 
have placed into a .zip file.  I tested out the zipped package by 
opening it directly onto my storage card (into 'Storage Card\temp' 
directory) using a card reader.  I then browsed to Storage 
Card\temp\sword and opened SwordReader and it works just fine!  A whole 
lot easier than trying to get Johan's version up and running the first 
time. 

I've put the full procedure on the attached which is in the .zip file.

Wuith regard to getting a successful x86 build of simplegui I haven't 
really tried, as everything that you change in GUI is also changed in 
simplegui.  I'm building and testing GUI, and when it's OK, building the 
ARM release of simplegui as the only useable frontend.  I't's probably 
not too difficult to locate the errors, but why bother?

There are times when I forget that I've been using and working with 
Sword for years, and a whole lot of things that are clear to me are not 
obvious to someone who has not already interacted with the engine.  I've 
done this mainly when making modules; for me the easiest thing was to 
write a C script to get the information, and then use calls to the 
engine to add this information to the module I am making.  I also dug 
out the old Cheatah front end (for GTK+) and got it up and running as a 
simple cross platform front end that would build using GNU both on 
Windows and Linux.  Cheatah was the starting point for GnomeSword (years 
and years ago). 

Playing around with Cheatah was good fun, but not a lot of use, so I 
left it on SourceForge (it's called XSword) hoping someone would carry 
the project on.  A couple of folk showed interest, and I added one of 
them as administrator, but apart from making a learning tool for Sword, 
no one seems to have wanted to take it to a next stage.  For me, it 
served its purpose: I found my way around the Sword engine!

God bless,
Barry

-- From Barry Drake (The Revd) minister of the Netherfield United Reformed church, Nottingham see http://www.jesusinnetherfield.org.uk for our church homepages).

Replies - b.drake at ntlworld.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: INSTALL.TXT
Url: http://www.crosswire.org/pipermail/sword-devel/attachments/20071127/f07d9a1e/attachment.asc 


More information about the sword-devel mailing list