[sword-devel] New Windows SWORD GUI / a design
Simon Lagendijk
sword-devel@crosswire.org
Sat, 13 Dec 2003 12:30:00 +0100
Thanks! I think it would really be nice to have them on the website.
Class Diagrams make it much easier to understand code..
Simon
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
>
>
>