<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Hi Tobias,</p>
    <p>I see how that would be useful to see what options are available
      in a module before install.</p>
    <p>I have added the the public SWModule::getOptionFilters method
      along with extending the listoptions.cpp example to which Peter
      pointed:</p>
    <p><a class="moz-txt-link-freetext" href="http://crosswire.org/svn/sword/trunk/examples/cmdline/listoptions.cpp">http://crosswire.org/svn/sword/trunk/examples/cmdline/listoptions.cpp</a></p>
    <p>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.</p>
    <p>I've also added this to the utilitites/installmgr -rdesc
      directive.  Thank you for the useful suggestion.</p>
    <p>Hope this is helpful,</p>
    <p>Troy</p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 5/5/19 9:12 AM, Tobias Klein wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:ea583a54-e358-6272-9b62-ef1ec4c32455@tklein.info">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>Hi Troy,</p>
      <p>I think the usecase I mentioned is maybe most relevant when
        installing modules.</p>
      <p>Well, I'm generating a table like this as meta information for
        bible translation modules:</p>
      <table style="color: rgb(54, 43, 54); font-family: &quot;Lucida
        Grande&quot;, &quot;Lucida Sans&quot;, Arial, sans-serif;
        font-size: 12.8256px; font-style: normal;
        font-variant-ligatures: normal; font-variant-caps: normal;
        font-weight: 400; letter-spacing: normal; orphans: 2;
        text-align: start; text-indent: 0px; text-transform: none;
        white-space: normal; widows: 2; word-spacing: 0px;
        -webkit-text-stroke-width: 0px; background-color: rgb(242, 245,
        247); text-decoration-style: initial; text-decoration-color:
        initial;">
        <tbody>
          <tr>
            <td style="width: 9em;">Name:</td>
            <td>engNET2016eb</td>
          </tr>
          <tr>
            <td>Version:</td>
            <td>25.2</td>
          </tr>
          <tr>
            <td>Language:</td>
            <td>English</td>
          </tr>
          <tr>
            <td>Strong's:</td>
            <td>Yes</td>
          </tr>
          <tr>
            <td>Headings:</td>
            <td>Yes</td>
          </tr>
          <tr>
            <td>Footnotes:</td>
            <td>No</td>
          </tr>
          <tr>
            <td>Cross references:</td>
            <td>No</td>
          </tr>
          <tr>
            <td>Red letter words:</td>
            <td>No</td>
          </tr>
          <tr>
            <td>Size:</td>
            <td>3628 KB</td>
          </tr>
        </tbody>
      </table>
      <br>
      So this is sort of a human-readable version of the module's conf
      file. <br>
      <br>
      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.<br>
      <br>
      <tt>bool moduleHasGlobalOption(SWModule* module, string
        globalOption)</tt><tt><br>
      </tt><tt>{</tt><tt><br>
      </tt><tt>    bool hasGlobalOption = false;</tt><tt><br>
      </tt><tt>    ConfigEntMap::const_iterator it =
        module-&gt;getConfig().lower_bound("GlobalOptionFilter");</tt><tt><br>
      </tt><tt>    ConfigEntMap::const_iterator end =
        module-&gt;getConfig().upper_bound("GlobalOptionFilter");</tt><tt><br>
      </tt><tt><br>
      </tt><tt>    for(; it !=end; ++it) {</tt><tt><br>
      </tt><tt>        string currentOption =
        string(it-&gt;second.c_str());</tt><tt><br>
      </tt><tt>        if (currentOption.find(globalOption) !=
        string::npos) {</tt><tt><br>
      </tt><tt>            hasGlobalOption = true;</tt><tt><br>
      </tt><tt>            break;</tt><tt><br>
      </tt><tt>        }</tt><tt><br>
      </tt><tt>    }</tt><tt><br>
      </tt><tt><br>
      </tt><tt>    return hasGlobalOption;</tt><tt><br>
      </tt><tt>}</tt><br>
      <br>
      I don't actually need additional Sword API features for toggling
      markup, only to retrieve the meta information for the modules.<br>
      <br>
      Best regards,<br>
      Tobias<br>
      <br>
      <div class="moz-cite-prefix">On 05.05.19 17:31, Troy A. Griffitts
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:6c11adf3-2d53-d10b-6a84-1a29cde612eb@crosswire.org">
        <meta http-equiv="Content-Type" content="text/html;
          charset=UTF-8">
        <p>Hi Tobias,</p>
        <p>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.</p>
        <p>I know at least Bibletime, at one point and probably still,
          lists the options per modules.</p>
        <p>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.</p>
        <p>But, I understand others have different study habits and that
          is why we have different user interfaces.</p>
        <p>So, having said all this... SWModule::optionFilters will give
          you a list&lt;OptionFilter *&gt; 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.</p>
        <p>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.</p>
        <p>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.</p>
        <p>Hope this is helpful,</p>
        <p>Troy</p>
        <p><br>
        </p>
        <div class="moz-cite-prefix">On 5/5/19 7:56 AM, Tobias Klein
          wrote:<br>
        </div>
        <blockquote type="cite"
          cite="mid:7f8e0795-fa3f-76ff-2f7b-7c917f584e03@tklein.info">
          <meta http-equiv="Content-Type" content="text/html;
            charset=UTF-8">
          <p>Hi Troy, Peter,</p>
          <p>Thank you! My usecase is to list the options available for
            one particular (bible translation) module.</p>
          <p>@Troy: The solution you suggested is probably what I need.
            Or are there better solutions based on my usecase mentioned
            above?<br>
            <br>
            Best regards,<br>
            Tobias</p>
          <div class="moz-cite-prefix">On 05.05.19 15:41, Troy A.
            Griffitts wrote:<br>
          </div>
          <blockquote type="cite"
            cite="mid:0A09B64E-5C4F-48B6-A24B-A2069EBDE218@crosswire.org">
            <meta http-equiv="content-type" content="text/html;
              charset=UTF-8">
            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 <br>
            <br>
            ConfigEntMap::const_iterator begin =
            module-&gt;getConfig().lower_bound("Key");<br>
            ConfigEntMap::const_iterator end =
            module-&gt;getConfig().upper_bound("Key");<br>
            <br>
            for(; begin !=end; ++begin) {<br>
            cout &lt;&lt; begin-&gt;first.c_str() &lt;&lt; " = "
            &lt;&lt; begin-&gt;second.c_str() &lt;&lt; endl;<br>
            }<br>
            <br>
            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.<br>
            <br>
            Troy<br>
            <br>
            <div class="gmail_quote">On May 5, 2019 2:04:11 AM MST,
              Peter von Kaehne <a class="moz-txt-link-rfc2396E"
                href="mailto:refdoc@gmx.net" moz-do-not-send="true">&lt;refdoc@gmx.net&gt;</a>
              wrote:
              <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
                0.8ex; border-left: 1px solid rgb(204, 204, 204);
                padding-left: 1ex;">
                <pre class="k9mail">On Sun, 2019-05-05 at 08:49 +0200, Tobias Klein wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Hi,
how is SWModule::getConfigEntry(const char *key) supposed to behave
when there are multiple entries with the same key?
</blockquote>
There is a set of separate methods for those.

Check out ./examples/cmdline/listoptions.cpp

<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> {
         SWMgr library;

         StringList options = library.getGlobalOptions();
         for (StringList::const_iterator it = options.begin(); it !=
 options.end(); ++it) {
                 cout &lt;&lt; *it &lt;&lt; " (" &lt;&lt;
 library.getGlobalOptionTip(*it) &lt;&lt; ")\n";
                 StringList optionValues =
 library.getGlobalOptionValues(*it);
                 for (StringList::const_iterator it2 =
 optionValues.begin(); it2 != optionValues.end(); ++it2) {
                         cout &lt;&lt; "\t" &lt;&lt; *it2 &lt;&lt; "\n";
                 }
         }

</blockquote><hr>sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org" moz-do-not-send="true">sword-devel@crosswire.org</a>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" moz-do-not-send="true">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
              </blockquote>
            </div>
            <br>
            -- <br>
            Sent from my Android device with K-9 Mail. Please excuse my
            brevity. <br>
            <fieldset class="mimeAttachmentHeader"></fieldset>
            <pre class="moz-quote-pre" wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org" moz-do-not-send="true">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel" moz-do-not-send="true">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page</pre>
          </blockquote>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <pre class="moz-quote-pre" wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org" moz-do-not-send="true">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel" moz-do-not-send="true">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page</pre>
        </blockquote>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <pre class="moz-quote-pre" wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org" moz-do-not-send="true">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel" moz-do-not-send="true">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page</pre>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page</pre>
    </blockquote>
  </body>
</html>