[sword-devel] New Windows SWORD GUI / a design
Simon Lagendijk
sword-devel@crosswire.org
Sat, 13 Dec 2003 02:06:49 +0100
Troy,
> I'm really encouraged by your enthusiasm, but would really like
> for you to cooperate in development with us. I'm not sure if you know
> this or not, but your diagram could have names changes and be the
> SWORD engine.
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.
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?
> We've even planned for some time to use OSIS as an intermediate
> markup, like you describe below (currently, the route is src->dest but
> would like it to be src->OSIS->dest, possibly: we're still hoping to
> do a proof of principle to see the speed impact and repercussions).
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.
> The only difference, is that we didn't write a 'driver' to read
> flat OSIS files, not because it wouldn't be an easy plugin to the
> engine, but because of a number of other conscious decision defended
> in an email a few weeks back (about half-way down regarding XML +/-):
>
> http://www.crosswire.org/pipermail/sword-devel/2003-November/019642.html
The text below is quoted from the mail which can be found at the above URL:
> Plain, raw XML is not ideal, at least in my opinion, for our
> applications of working with data. It's an excellent archival and
> interchange format, but for realtime interaction and processing it has
> some of these problems:
> o Many duplicated tokens (e.g. word level markup) that make file sizes
> huge, not catering to PDAs and other devices with storage limitations.
> o Top down processing to know what 'level' and other 'context' you are
> within a document, which makes segmentation retrieval and display difficult.
> It seems to me that using XML as a base document for your software will
> require many indices and other auxiliary files being build based on the
> document to allow fast retrieval and context hints. My conclusion would
> be that, it seems, if you are going to preprocess the document anyway,
> it might be best to use a compressed, or otherwise optimized format
> suited to your software needs. Preserving the original XML document
> doesn't seem to be beneficial.
> Having said all of this, I just want to restate, we would LOVE to
> colabor with you for our Lord! We definitely NEED someone to own the
> OSIS import support and other XML processing tasks in the engine.
First, I don't share the idea that XML is only a interchange format.
Indexes that contain Book-Chapter-Verse info are very easy to create,
fast to access, and can be very small (using the right techniques).
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.
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
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...
Last, I want to write a script that automatically converts
HTML/ThML/Text documents to OSIS. 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). If that script is ready, tons of theological
documents (mostly books) will be available in OSIS format. It would be
nonsense if a user needs to wait until a OSIS text is converted to a
module, before he can use it.
>
> We could sure use your help. Please consider joining together
> with us in this work.
I have considered, and you're totally right. Any restrictions that apply
for code submitted to the Sword Project (besides that it has to be
easy-to-read, and under GPL)? If there is a todo list (including
priorities), please let me know...
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.
* I noticed the Sword Engine uses a unicode library. In what way is that
compatible with the wxString type of wxWindows?
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
>