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

[Troy A. Griffitts]

Martin,
	I can link to them from the website.  I have no problem with that at all.

	BUT, I remember myself not being able to understand the class diagrams 
and comments produced by doxygen.  I realize this is probably my fault 
for not commenting the code better, but I would like a human made 
diagram with comments, in the long run.

	You can check out the docs from your account on crosswire and link to 
them from wiki, right?  Or did you have a specific place from the public 
website that you'd like a link placed?  Just let me know and I'll be 
happy to do it.

	-Troy.



Martin Gruner wrote:
> 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
> 
> 
> _______________________________________________
> sword-devel mailing list
> sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel