<br><br><div><span class="gmail_quote">On 1/22/06, <b class="gmail_sendername">Chris Little</b> &lt;<a href="mailto:chrislit@crosswire.org">chrislit@crosswire.org</a>&gt; 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, &amp; KJV, etc.)</blockquote><div><br>OK, so that makes more sense and seems like a really good idea, in my opinion.&nbsp; 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.&nbsp; 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&nbsp; be configurable for any module that I want to see the notes for.&nbsp; 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.&nbsp; 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>&gt; Is it necessary that the library utilize saved conf files for this
<br>&gt; construct?&nbsp;&nbsp;I really like the ability to dynamically swap modules in and<br>&gt; out, and that seems like it would require the creation of new .conf<br>&gt; files for every module combination that is desired.&nbsp;&nbsp;It seems to me that
<br>&gt; the number of parallel texts could rapidly expand out of hand in this<br>&gt; way.&nbsp;&nbsp;Just presuming a basic install had some 10 modules installed, then<br>&gt; that person could have 10! module combinations if they don't repeat any,
<br>&gt; and an unlimited combination if they repeat modules.&nbsp;&nbsp;Numbers that grow<br>&gt; exponentially, especially if they are related to constrcuts in memory or<br>&gt; on disk, scare me.<br>&gt;<br>&gt; I think providing the interface to a parallel module would be great, and
<br>&gt; possibly allowing a .conf file to specify some predefined ones would be<br>&gt; useful, but I think that the most useful parallel construct would simply<br>&gt; be a dynamically accessible parallel module (with or without a limit to
<br>&gt; modules viewable in parallel) which the front-end could swap in and out<br>&gt; for different module texts as well as add and remove them on-the-fly.<br>&gt; It might be a little tricky to specify the interface for adding and
<br>&gt; removing texts, especially if one text (such as the ASV) could be<br>&gt; inserted multiple times to get a parallel view of<br>&gt; ASV-KJV-ASV-ALT-ASV-TR-etc.&nbsp;&nbsp;But I think that would be most useful... at<br>&gt; least in my experience and thought.
<br>&gt;<br>&gt; --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>