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
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
