Hi Troy,
I think the usecase I mentioned is maybe most relevant when installing
modules.
Well, I'm generating a table like this as meta information for bible
translation modules:
Name: engNET2016eb
Version: 25.2
Language: English
Strong's: Yes
Headings: Yes
Footnotes: No
Cross references: No
Red letter words: No
Size: 3628 KB
So this is sort of a human-readable version of the module's conf file.
I just implemented a method to query on this type of information - based
on your earlier tip. I guess something like this could be integrated in
the Sword API to make it more accessible/convenient.
bool moduleHasGlobalOption(SWModule* module, string globalOption)
{
bool hasGlobalOption = false;
ConfigEntMap::const_iterator it =
module->getConfig().lower_bound("GlobalOptionFilter");
ConfigEntMap::const_iterator end =
module->getConfig().upper_bound("GlobalOptionFilter");
for(; it !=end; ++it) {
string currentOption = string(it->second.c_str());
if (currentOption.find(globalOption) != string::npos) {
hasGlobalOption = true;
break;
}
}
return hasGlobalOption;
}
I don't actually need additional Sword API features for toggling markup,
only to retrieve the meta information for the modules.
Best regards,
Tobias
On 05.05.19 17:31, Troy A. Griffitts wrote:
Hi Tobias,
Yeah, so in my frontends, I usually just have a toolbar or option menu
which has associated buttons or menu checkbox toggles for any options
available in the installed module set, which can be obtained, along
with suggested option names, tooltips, options value (if more than
simply On and Off are available) with the code Peter sent.
I know at least Bibletime, at one point and probably still, lists the
options per modules.
My usecase is typically: I want to toggle Strongs and Morphology for a
second while I do a word study; I want to turn footnotes on or off,
etc. I typically don't care if it is done for one particular module.
I just want them either on or off.
But, I understand others have different study habits and that is why
we have different user interfaces.
So, having said all this... SWModule::optionFilters will give you a
list<OptionFilter *> for any module. The problem right now is that
this property is protected. You would need to expose this in a
derived class and override SWMgr::createModule to construct your
derived class instead of the ones created in the default
implementation. That would suck and isn't the path I would want you
to go down.
So, I can add a public getOptionsFilters() method for you to access
this, if you really wish to know exactly which option filters are
available on a per module basis. That's simple and would help other
who wish to show per module options.
There is one caveat though, the default implementation of
SWMgr::addGlobalOptionFilters only constructs one instance of each
type of filter and reuses it for all modules which want that same
filter. This is how, e.g., toggling Strongs numbers toggles it for
all modules. If you indeed wish to allow toggling of an option for a
single module, but not others, then you'd want to override
SWMgr::addGlobalOptionFilters and make it work more like
SWMgr::addLocalOptionFilters, which constructs an instance of the
filter for each module, and thus would allow you to toggle one option
for a module and not affect that same logical option class for any
other module.
Hope this is helpful,
Troy
On 5/5/19 7:56 AM, Tobias Klein wrote:
Hi Troy, Peter,
Thank you! My usecase is to list the options available for one
particular (bible translation) module.
@Troy: The solution you suggested is probably what I need. Or are
there better solutions based on my usecase mentioned above?
Best regards,
Tobias
On 05.05.19 15:41, Troy A. Griffitts wrote:
While Peter is correct about how to find all the options that any
loaded module might allow for toggling by an end user... and if this
is your purpose, you should certainly use the methods Peter
suggested... your question as to more generally how to read config
entries which have the same key values is answered by how to iterate
a multimap in C++. SWModule::getConfig returns the full multimap of
config entries. Something like this should work:Hi
ConfigEntMap::const_iterator begin =
module->getConfig().lower_bound("Key");
ConfigEntMap::const_iterator end =
module->getConfig().upper_bound("Key");
for(; begin !=end; ++begin) {
cout << begin->first.c_str() << " = " << begin->second.c_str() << endl;
}
But I've never needed to do this as a client of the library. Maybe
if you tell us your use case, we can recommend a facility in the
system which might make things easier for you.
Troy
On May 5, 2019 2:04:11 AM MST, Peter von Kaehne <ref...@gmx.net> wrote:
On Sun, 2019-05-05 at 08:49 +0200, Tobias Klein wrote:
Hi, how is SWModule::getConfigEntry(const char *key)
supposed to behave when there are multiple entries with the
same key?
There is a set of separate methods for those.
Check out ./examples/cmdline/listoptions.cpp
{ SWMgr library; StringList options =
library.getGlobalOptions(); for (StringList::const_iterator
it = options.begin(); it != options.end(); ++it) { cout <<
*it << " (" << library.getGlobalOptionTip(*it) << ")\n";
StringList optionValues =
library.getGlobalOptionValues(*it); for
(StringList::const_iterator it2 = optionValues.begin(); it2
!= optionValues.end(); ++it2) { cout << "\t" << *it2 <<
"\n"; } }
------------------------------------------------------------------------
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
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
