[sword-devel] virtual modules

[Greg Hellings]

On 1/22/06, Chris Little <chrislit at crosswire.org> wrote:
>
> I am actually talking about dynamically creating the configurations
> themselves (using SWConfig). So a user would use the frontend to
> manually add some set of modules to a new parallel virtual module (or
> remove them). Each time the configuration is changed, SWConfig would
> write out its new configuration to a .conf file. Thus, the next time the
> user starts his frontend, the same parallel view would be available.
> (Plus the user could create multiple such parallel views--say one for
> his 4 favorite English Bibles, one for parallel WLC, LXX, & KJV, etc.)


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.

My vision for the implementation of a basic notes virtual module in
> BibleCS currently would require that every change of the active Bible
> text notify the notes module to change its base module. For example, if
> you're viewing the KJV and switch to the NASB, BibleCS would change the
> configuration of the notes module, changing its base module from KJV to
> NASB (regardless of whether the notes module happens to be the
> commentary currently selected). However, an alternative would be to
> allow the user to select which module a notes window displays. Thus, a
> user could configure a notes virtual module to display the notes and/or
> cross-references from any specific module, regardless of which module is
> currently visible (permitting the user to view, e.g. the notes from the
> NET Bible along with the text of the NASB). But I don't know whether
> this would be a useful addition since most texts will have footnote
> markers, without which a note may not be particularly clear.


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.

--Greg

--Chris
>
>
> Greg Hellings wrote:
> > Is it necessary that the library utilize saved conf files for this
> > construct?  I really like the ability to dynamically swap modules in and
> > out, and that seems like it would require the creation of new .conf
> > files for every module combination that is desired.  It seems to me that
> > the number of parallel texts could rapidly expand out of hand in this
> > way.  Just presuming a basic install had some 10 modules installed, then
> > that person could have 10! module combinations if they don't repeat any,
> > and an unlimited combination if they repeat modules.  Numbers that grow
> > exponentially, especially if they are related to constrcuts in memory or
> > on disk, scare me.
> >
> > I think providing the interface to a parallel module would be great, and
> > possibly allowing a .conf file to specify some predefined ones would be
> > useful, but I think that the most useful parallel construct would simply
> > be a dynamically accessible parallel module (with or without a limit to
> > modules viewable in parallel) which the front-end could swap in and out
> > for different module texts as well as add and remove them on-the-fly.
> > It might be a little tricky to specify the interface for adding and
> > removing texts, especially if one text (such as the ASV) could be
> > inserted multiple times to get a parallel view of
> > ASV-KJV-ASV-ALT-ASV-TR-etc.  But I think that would be most useful... at
> > least in my experience and thought.
> >
> > --Greg
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/sword-devel/attachments/20060122/2b91bc1b/attachment-0001.html