<br><br><div><span class="gmail_quote">On 1/22/06, <b class="gmail_sendername">Chris Little</b> <<a href="mailto:chrislit@crosswire.org">chrislit@crosswire.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I am actually talking about dynamically creating the configurations<br>themselves (using SWConfig). So a user would use the frontend to<br>manually add some set of modules to a new parallel virtual module (or<br>remove them). Each time the configuration is changed, SWConfig would
<br>write out its new configuration to a .conf file. Thus, the next time the<br>user starts his frontend, the same parallel view would be available.<br>(Plus the user could create multiple such parallel views--say one for
<br>his 4 favorite English Bibles, one for parallel WLC, LXX, & KJV, etc.)</blockquote><div><br>OK, so that makes more sense and seems like a really good idea, in my opinion. I like the fact that it is persistent across multiple restarts of the front-end and would, presumably, be carried from one front-end to another that supports the same virtual parallel module mechanism. I like your thinking for that.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">My vision for the implementation of a basic notes virtual module in<br>BibleCS currently would require that every change of the active Bible
<br>text notify the notes module to change its base module. For example, if<br>you're viewing the KJV and switch to the NASB, BibleCS would change the<br>configuration of the notes module, changing its base module from KJV to
<br>NASB (regardless of whether the notes module happens to be the<br>commentary currently selected). However, an alternative would be to<br>allow the user to select which module a notes window displays. Thus, a<br>user could configure a notes virtual module to display the notes and/or
<br>cross-references from any specific module, regardless of which module is<br>currently visible (permitting the user to view, e.g. the notes from the<br>NET Bible along with the text of the NASB). But I don't know whether
<br>this would be a useful addition since most texts will have footnote<br>markers, without which a note may not be particularly clear.</blockquote><div><br>I, personally, would prefer to see the module be configurable for any module that I want to see the notes for. Thus, I might prefer to be looking at the TR, but I want to see what the English translators have had to say about the differences between Greek texts or alternative translations and interpretations, so I would like to pull out the NASB or ASV notes. Granted, that would be entirely up to the front-end with your concept of the implementatoin, since the front-end would be responsible for notifying the library that a change had been made.
<br><br>--Greg<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">--Chris<br><br><br>Greg Hellings wrote:<br>> Is it necessary that the library utilize saved conf files for this
<br>> construct? I really like the ability to dynamically swap modules in and<br>> out, and that seems like it would require the creation of new .conf<br>> files for every module combination that is desired. It seems to me that
<br>> the number of parallel texts could rapidly expand out of hand in this<br>> way. Just presuming a basic install had some 10 modules installed, then<br>> that person could have 10! module combinations if they don't repeat any,
<br>> and an unlimited combination if they repeat modules. Numbers that grow<br>> exponentially, especially if they are related to constrcuts in memory or<br>> on disk, scare me.<br>><br>> I think providing the interface to a parallel module would be great, and
<br>> possibly allowing a .conf file to specify some predefined ones would be<br>> useful, but I think that the most useful parallel construct would simply<br>> be a dynamically accessible parallel module (with or without a limit to
<br>> modules viewable in parallel) which the front-end could swap in and out<br>> for different module texts as well as add and remove them on-the-fly.<br>> It might be a little tricky to specify the interface for adding and
<br>> removing texts, especially if one text (such as the ASV) could be<br>> inserted multiple times to get a parallel view of<br>> ASV-KJV-ASV-ALT-ASV-TR-etc. But I think that would be most useful... at<br>> least in my experience and thought.
<br>><br>> --Greg<br><br>_______________________________________________<br>sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br><a href="http://www.crosswire.org/mailman/listinfo/sword-devel">
http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>Instructions to unsubscribe/change your settings at above page<br></blockquote></div><br>