Nathan,
Sorry for not getting back to you sooner. I'm excited about your
efforts!!! You don't know how many times people have asked, "do you
anything for the Mac?"
Good place to start to understand some of the basics of the API are:
API Primer:
http://www.crosswire.org/sword/develop/swordapi/apiprimer.jsp
tests:
sword/tests
utilities:
sword/utilities
examples:
sword/examples
(which, it seems, you've already found)
To answer some of your questions:
You shouldn't need to ever call setBooks(...) unless you're doing
something to extend the lib.
see sword/tests/parsekey for an example of how to get book names in
another locale (e.g. try parsekey "jn1:1-5,9;jas2" de), provided you
have locales.d/*.conf installed same place as your mods.d directory
To get book name from a VerseKey, you may use const char
*VerseKey::getBookName()
You might want to access the books structure directly for some
circumstances, but mostly it's used internally by methods like
getBookName.
Here's how you'd do it with the books member:
VerseKey key = "jn1:1";
key.books[key.Testament()-1][key.Book()-1].name;
You may jump to the end of a chapter or book with the positioners:
MAXCHAPTER and MAXVERSE
key = MAXCHAPTER;
key = MAXVERSE;
RE searching. The engine defaults to a scan text search. No indecies
are used. Each driver is welcome to implement a searching mechanism
that may be more efficient for the way the driver stores text. There is
an example of such in the RawText driver. There is a utility that will
call an initializer (to build indexiced, or what have you) that the
driver may need to do on a text. You can try running it:
sword/utilities/mkfastmod. If you run it on any module that has
ModDrv=RawText you will get indexed search example for multiword
searches, from that point on, for that module. The hope was that
drivers would implement indexed searches in the future, and we have
individuals volunteering for such work. So maybe in the future it will
be faster. AGAIN, the RawText::Search is JUST AN EXAMPLE of how to
override the default search mechanism, it was never intended to be used
for production :)
That said. We usually do an optimization pass now and again, and can
get a given search down to about 2 seconds max on a decent machine. My
1.4Ghz box usually gets about .8 seconds.
Please ask questions here or join #sword on irc.openprojects.net!
Talking to people who've waded thru an API is the quickest way to learn
one!
-Troy.
Nathan Youngman wrote:
>
> Well - I haven't necessarily done the best tests. I tried the search
> example, which was pretty slow. Threaded_search was better, and maybe
> implemented in a GUI with results being displayed progressively
> would be okay. I did try the Windows client, but only under Virtual
> PC under Mac OS X - which tends to be slow for everything :-).
>
> I will try some kind of progressive display to minimize any
> "perceived slowness" - that is, whenever I get to searching. Right
> now I'm still just trying to figure out how to get data from VerseKey
> to populate my interface. Long ways to go...
>
> Of course if the speed can be improved - that couldn't be a bad
> thing. It will be nice to swap out the 1.5.3 library with a newer one
> and suddenly everything is faster/better :-).
>
> - n8
>
> >Well, I'm excited now because I think I have found something that I could
> >work on. In my experience with sword searching was actually quite quick and
> >I never really had a 'slow' search. However, if you (all of you, any of
> >you) see a need for a better search technique I would be willing to try to
> >get that running more smoothly. As soon as I upgrade from msvc++ to BCB5
> >and install the necessary components I will be glad to work on this...
>
> --
> Nathan Youngman
> E-mail: sword at nathany.com
> Web: http://nathany.com
