Re: [sword-devel] Behavior of SWModule::getConfigEntry in case of multiple entries with same key
Hi Tobias, I see how that would be useful to see what options are available in a module before install. I have added the the public SWModule::getOptionFilters method along with extending the listoptions.cpp example to which Peter pointed: http://crosswire.org/svn/sword/trunk/examples/cmdline/listoptions.cpp It protects you from needing to know all possible option filter names (e.g., GBFStrongs, OSISStrongs, etc.) and should be dynamically extend when we add new options. I've also added this to the utilitites/installmgr -rdesc directive. Thank you for the useful suggestion. Hope this is helpful, Troy On 5/5/19 9:12 AM, Tobias Klein wrote: > > 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 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
Re: [sword-devel] Behavior of SWModule::getConfigEntry in case of multiple entries with same key
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 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 wrote: On Sun, 2019-05-05 at 08:49 +0200, Tobias Klein wrote: Hi, how is SWModule::getConfigEntry(const char *key)
Re: [sword-devel] Behavior of SWModule::getConfigEntry in case of multiple entries with same key
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 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 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
Re: [sword-devel] Behavior of SWModule::getConfigEntry in case of multiple entries with same key
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 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
Re: [sword-devel] Behavior of SWModule::getConfigEntry in case of multiple entries with same key
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: 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 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
Re: [sword-devel] Behavior of SWModule::getConfigEntry in case of multiple entries with same key
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
[sword-devel] Behavior of SWModule::getConfigEntry in case of multiple entries with same key
Hi, how is /SWModule::getConfigEntry(const char *key)/ supposed to behave when there are multiple entries with the same key? Like these entries in case of the engNET2016eb module: GlobalOptionFilter=OSISStrongs GlobalOptionFilter=OSISHeadings It seems like it stops at the first entry in cases like this. Can you point me to an example where this situation is handled? (Reading back multiple values for one key) Best regards, Tobias ___ 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