[sword-devel] New Windows SWORD GUI / a design

Martin Gruner sword-devel@crosswire.org
Sat, 13 Dec 2003 12:15:36 +0100


Simon,

I maintain the API-docs for Sword, and they do contain a few class diagrams 
and such. Please checkout the sword-apidoc module from cvs.

Troy, can we have this on the website somewhere?

Martin

Am Samstag, 13. Dezember 2003 02:06 schrieb Simon Lagendijk:
> 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
>
> _______________________________________________
> sword-devel mailing list
> sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel