Troy A. Griffitts wrote:
I've been listening to the discussion and ideas but haven't had too
much time to comment. I like the idea of providing these 'virtual
modules' as dropin solutions for frontend developers. It's a great
idea. I think we discussed previously that I would like for us to add
an 'extras' directory or similar to the engine source where we can dream
and place code that _uses_ the engine for unique things.
Sounds like a good idea.
What do you
think about your SWModule subclass idea (whether from EchoMod, SWText,
SWCom, or whavever) being available from there and utilized by a
frontend with something like:
#include <parallelmodules.h>
SWModule *parallel = new ParallelModules();
parallel->addModule(mgr->getModuleByName("KJV"));
parallel->addModule(mgr->getModuleByName("ASV"));
parallel->addModule(mgr->getModuleByName("WEB"));
mgr->addModule(parallel);
SWMgr would then be smart enough to query the source type, which you'd
return OSIS, and then it would add the, e.g., OSISRTF (for BibleCS)
filters, when you call add the module to SWMgr.
I'm still pretty sold on the idea of using the existing SWConfig system
to handle specifying which modules are references and loading
from/saving to disk. But I suppose there would be some sense to delaying
load of virtual modules (i.e. removing it from default SWMgr behavior)
and letting the frontends do loading & adding to SWMgr themselves, if
they desire to support the virtual module class(es).
--Chris
_______________________________________________
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
