[sword-devel] virtual modules

[Chris Little]

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.)

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.

--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