[sword-devel] New Windows SWORD GUI / a design
Troy A. Griffitts
sword-devel@crosswire.org
Fri, 12 Dec 2003 21:48:59 -0700
Simon, Apologies for less than I'd like detail. I'm trying to finish a
procrastinator's schedule for the end of the semester on Monday.
Simon Lagendijk wrote:
> I wasn't aware of that. I searched the crosswire website for some
> diagrams, but couldn't find one. But if the Sword Engine does already
> contain a nice architecture, I can better spend my time in programming
> with the Sword Engine.
Thank you for your heart! It's hard sometimes when it seems people
might be more interested in starting their own project than working
together.
> One question about the architecture of the Sword Engine: Does each
> module knows what it contains? In other words: if I have a bible module,
> does that module 'knows' which bible books it contains, and how much
> verses in each chapter? The reason I ask is because I don't want a fixed
> versification scheme, like that of the KJV, which makes it impossible to
> have the apocryphia or the book of mormon, or what else people want to
> add as an addiction to the canonical books (I am a protestant christian,
> so for me the apocryphia not that important, but there are people who
> consider them as holy). Another reason for wanting to have that
> information is to only show the biblebooks the module really contains.
> Can you please tell me if this problem exists, and what is planned to
> fix it?
Here's a little detail on the SWORD architecture.
Re: A couple base classes: SWModule and SWKey.
SWModule is the base class of all module drivers and 'has' an SWKey.
The key is the device used to position the module to a location.
e.g.
SWMgr mgr; // finds all Bibles installed on the system.
SWModule &kjv = *mgr["KJV"]; // grab the KJV
kjv.setKey("John 3:16");
cout << kjv;
Bibles, Commentaries, Lexicons, Dictionaries, General Books, are all
decendents of SWModule, and they all supply their own specific SWKey
decendent.
The current SWKey decendent that the Bible class uses is called VerseKey
and is hardcoded with the KJV versification.
VerseKey used to use files to load it's versification, but about 8 years
ago, every Bible we had used KJV and all these files where duplicated
identically. I think it was during an optimization pass that we just
hardcoded the table in the class, but it's been on our todo list to
revert back to a similar behaviour.
> Well, If nobody's working on it, maybe I can give it a try. The only
> problem is that I have to relearn C++ (last 4 years I've been working
> with Delphi and assembly, not much with C++), and get used to the
> wxWindows library and the Sword Engine, but I think that within a month
> I am as used to C++ as I am now to Delphi.
We have some CLX controls somewhere in the source that wouldn't take
much work to get compiling again :) But jumping in and relearning C++,
since your interface would be in wxWindows is probably the best :)
> First, I don't share the idea that XML is only a interchange format.
Well, that's a pretty general statement, but in the context of the
conversation it was referring to, the issue went something like: if
you're going to break the 20 meg Bible up into smaller, more usable XML
chunks, then you might as well just process the Bible into a useful,
compressed, optimized internal format, and keep all the ugly OSIS
normalization (because OSIS has a quite a few ways to encode the same
thing) code to handle all types of markup all in an importer.
I think XML is good for SAX parsing-- one sequential pass of an entire
document, for say, printing or other transformation.
I think XML is good for DOM manipulation of reasonably sized documents <
500k. There aren't many DOM parsers that do very well, or even work
at all when you get up above 3 megs.
> Indexes that contain Book-Chapter-Verse info are very easy to create,
> fast to access, and can be very small (using the right techniques).
Agreed, that's not the issue. Our 2 current Bible drivers, zText and
RawText, both build indecies. RawText can leave the document unchanged
and could likely do what you want with an OSIS document.
> Secondly, I don't know if the Sword Engine has indexes for fulltext
> searches, but those can be created the same way for XML documents.
Right, we have a search plugin mechanism in the engine (which needs to
be reworked a little). Haven't officially announced this yet, but
current CVS contains clucene as a plugin. The web interface uses this
plugin for a number of Bibles, including the default NASB. You can try
all clucene syntax and see the results and score:
http://www.crosswire.org/sword/biblenew/passagestudy.jsp
We need to update our clucene library to the latest, as a few things
like ~3 (within 3 words) returns strange things. Hope they've fixed the
bugs.
http://jakarta.apache.org/lucene/docs/queryparsersyntax.html
> Thirdly, I think supporting an well described format (like OSIS) with
> keeping the original file intact, instead of converting to a own module
> format, has some advantages. It makes the user more or less independant
> from the module making communitie, they can download an OSIS file, press
> the 'create indeces' button, and the document can be used
I don't see why keeping the document in OSIS format makes this possible.
Our current thinking to provide an OSIS importer would also allow this.
> Fourth, OSIS contains a lot of info about the text which is not saved in
> the module (correct me if I'm wrong). For example, take the CEV OSIS
> file, some verses are merged, it contains introductions, etc...
I'm not sure what you mean about 'not saved in the module'. If the data
is not captured, then it is a lack of _our support_ for some of that
data and a deficiency on our part. We're hoping to fully support OSIS soon.
> Last, I want to write a script that automatically converts
> HTML/ThML/Text documents to OSIS.
We have many documents saved as ThML. You can ask the engine for OSIS
markup and no matter what the source document is (ThML, GBF, OSIS),
correct filters will be applied to give you OSIS output. That's already
working to the extent that we support certain elements of each markup.
> A friend of me is working on a program
> and website that can display and print OSIS files in a eastetic form.
> The idea behind it is that most theological documents on the internet
> have a very ugly layout (bold typeface, difficult to read background,
> unreadable font, etc).
Right, we also support the other direction. The new NASB module (also
not announced yet, but should be publicly available from Lockman soon)
is stored in OSIS markup (not an OSIS flat file, but sliced into verse
chunks and compressed and indexed) and all of our frontends that make
engine calls can ask for the data in their desired markup: RTF, HTML,
even ThML, if they want.
> If that script is ready, tons of theological
> documents (mostly books) will be available in OSIS format.
Yes! conversion to OSIS is a good thing! Actually, I believe Harry
(CCEL) has a button you can click to get any of his documents as OSIS.
> It would be
> nonsense if a user needs to wait until a OSIS text is converted to a
> module, before he can use it.
Not sure what you mean 'wait until OSIS text is converted to a module'.
This process, in my mind is identical to your idea: "they can download
an OSIS file, press the 'create indecies' button, and the document can
be used"
I think we are on very much (amazingly so) the same page, just some
terminology differences and only a few 'real' difference that I hope I
can convince of 'better' ways :)
> I have considered, and you're totally right.
Well, it's not me. I just think it's silly for Christian to all be out
there competing to spread the Word of Christ. We're all about community
for common goals!
> Any restrictions that apply
> for code submitted to the Sword Project (besides that it has to be
> easy-to-read, and under GPL)?
Well, there is a CODINGSTYLE document at the root of the source tree.
Also, you are welcome to build all kinds of programs using the SWORD
engine, but if you want code included by CrossWire into the engine
itself and distributed by CrossWire, then we request copyright of the
code be given to CrossWire so we can legally control all the code in our
repository.
If there is a todo list (including
> priorities), please let me know...
I was about to post one on Wednesday for the 1.5.7 release due out
Christmas.
>
> Some last question:
> * Can the Sword Engine be compiled with MinGW? I don't have Borland C++
> Builder or Visual C++, and prefer a free compiler (like MinGW) much
> above those commercial ones.
Yes, it compiles with most all C++ compiles that I know of now (now that
someone actually got Microsoft's embedded C++ to compile it). That's
the 'engine', not necessarily any frontend.
> * I noticed the Sword Engine uses a unicode library. In what way is that
> compatible with the wxString type of wxWindows?
Haven't looked at wxString, but ICU is conditionally compiled into the
library. You don't have to use it. If you include it, you get cool
stuff like Arabic font shaping and transliteration.
Hope this helps. I'm really excited to work together, and should be
more attentive after Monday!
-Troy.
>
> In Christ,
>
> Simon
>
>>
>> In Christ,
>> -Troy.
>>
>> PS. Blessings on your paper!
>> PPS. OSIS 1.1.1 docs are available here:
>> http://bibletechnologieswg.org/osis/docs/
>>
>> Simon Lagendijk wrote:
>>
>>> Hi all,
>>>
>>> Thanks for your reply. Currently I'm using MinGW Studio for the
>>> programming, MinGW as compiler, and VisualWx for the form designing.
>>> It's does not work as well as, let say, Delphi, but its good enough
>>> to work with, and its free!
>>>
>>> Development has stopped for this week because I've to write an essay
>>> for English class. As subject I choose 'ethics in a computer age',
>>> it's about the negative side of the computer age (about wasting time,
>>> unwanted temptations (porno), etc, and about how to deal with it).
>>> Very nice to see how, even on a non-christian school, lots of people
>>> admit the existence of those problems. If someone knows some good
>>> texts about this topic, please let me know....
>>>
>>> Next week I hope to have a simplified OSIS reader ready, including a
>>> test app (console app). When thats finished, I'm going to work on the
>>> TagConversion (conversion of OSIS tags to HTML). When the HTML
>>> conversion is working, the GUI will be made (text showing will be
>>> done in a wxHTML control, so displaying text won't be to difficult).
>>> When that all is working, I'm going to implement the SWORD Engine. My
>>> idea is to support multiple 'reading engines', which are all
>>> independant from the original code, and all output OSIS, which will
>>> be converted to the format needed. Take a look at the attachment for
>>> an illustration of that idea.
>>>
>>> PS> I do not want to offend anyone here by not just implementing the
>>> Sword Engine at the start, but I want first to have something wich is
>>> relatively simple working, and then add the more complex parts.
>>>
>>> Simon
>>>
>>>
>>>> Simon,
>>>>
>>>> I believe you earlier asked about cross-development compiler tools for
>>>> Windows development?
>>>>
>>>> If I understand your question (and if it was you that asked), there are
>>>> several alternatives that I am aware of.
>>>>
>>>> 1. Al Stevens donated "Quincy" for free usage. It is a relatively
>>>> simple ide
>>>> that utilizes a gnu based compiler/linker back-end. It comes with
>>>> several
>>>> editions of his "Teach Yourself C++". The 2002 version comes with
>>>> edition 7.
>>>> It is mostly to facilitate building the sample code in his book. Kinda
>>>> cool, but probably only adequate for early prototypes?
>>>>
>>>> 2. The Palm interface to the InVerse Scripture memorization freeware
>>>> used
>>>> the cgywin command line tools. It also uses gnu based compiler
>>>> back-end. For
>>>> me, I had to struggle to set it up, since I have little or no Linux
>>>> experience. There may very well be an ide. My impression is that a very
>>>> similar setup could be used for the development you have proposed,
>>>> except
>>>> some of the Palm specific files replaced. (someone else on this list
>>>> probably is far more aware than I on this)
>>>>
>>>> If you are interested and/or still need info, I can hunt around for
>>>> links
>>>> and directions.
>>>>
>>>> HTH and sharing the reason for the season,
>>>> http://learningcards.eeworks.org/EeCard01.html
>>>>
>>>> Lynn A
>>>>
>>>>
>>>> _______________________________________________
>>>> sword-devel mailing list
>>>> sword-devel@crosswire.org
>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>>
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>
>> _______________________________________________
>> sword-devel mailing list
>> sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>
>
> _______________________________________________
> sword-devel mailing list
> sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel