<div dir="ltr"><div>In terms of missing out a line in the conf file, then presumably one would simply fix it. In fact, that's where this thread originated from, as suddenly unexpected introductions started appearing and appeared as other canonical content. I had the same issue previously with colophons, which were appearing at the end of books, in the same font/display as the rest of the book. Both of these were undesirable.<br>
</div><div><br></div>But that's fine. I was just trying to make everybody's frontend better by storing some more reference data similar to the ones that exist already, the ones DM mentioned before, and the ones I have mentioned. These settings are not environment specific, nor user specific, and are safe to distribute over the wire (i.e. not a personal Cipher key). <div>
<br></div><div>STEP can store its own list of settings per module like Troy suggests and we can implement something along the lines of the sidecar DM suggested in JSword. I just thought that others would want that data, rather than it being stored in the STEP source code in thereby duplicating anyone coming after me.</div>
<div><br></div><div style>I guess I fail to understand the purpose of the .conf module since it defines things like headers, red letters, cross references, etc. which are all computable.</div><div>Chris</div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 June 2013 15:23, Troy A. Griffitts <span dir="ltr"><<a href="mailto:scribe@crosswire.org" target="_blank">scribe@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't recall ever hearing of "NoParagraphs". But I am old now and quite possibly could have forgotten.<br>
<br>
The push back on my side of this is from the desire to:<br>
<br>
a) keep the .conf generation only as complex as needed, and<br>
b) avoid the possibilities for inconsistencies.<br>
<br>
SWORD accumulates toggleable features from all installed modules and presents them from:<br>
SWMgr::getGlobalOptions()<br>
<br>
This will only return a list of available options from installed modules, even if the software supports more options.<br>
<br>
In the frontends I have written, I call this method, and typically present an application toolbar for global toggling of these features. Many frontends decide that their user might want to toggle these features on a per-module basis, instead of globally, and while my preference is otherwise, I am happy to have frontends which support both methodologies.<br>
<br>
I am not happy to have computed values in the .conf file. This makes independent module publishing more difficult. I've already reluctantly gone down that road for "InstallSize", which if not present merely has the side-effect of saying something like "Unknown" in the installer. If we start writing code which depends upon computed values and the publisher forgets to add "Feature=Headings" in the .conf file-- making it inconsistent with what actually is in the module, what are the results?<br>
<br>
I am not sure I am convinced of a need to precompute the existence of all possible OSIS tags within a document that a frontend might wish to expose user features against-- which is the logical end to this request.<br>
<br>
The Feature tags which exist were added for specific use cases.<br>
<br>
Select your preferred Greek Lexicon: [ modules(@Feature=GreekDef) ]<br>
Select your preferred Hebrew Lexicon: [ modules(@Feature=HebrewDef) ]<br>
Select your preferred Chinese Glossary: [ modules(@Lang=zh,@Feature=<u></u>Glossary ]<br>
<br>
etc.<br>
<br>
<br>
The OptionFilter tags are used by a publisher to state that they would like a user to be able to toggle certain features within their module. These are what register option for the getGlobalOptions mentioned above.<br>
<br>
Troy<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Troy</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 06/03/2013 02:55 PM, DM Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I saw that Scope was yanked from the wiki with a comment that it had been rejected. I really don't remember it being rejected. I just remember that the discussion never went anywhere so it was dropped. I documented the desire of that discussion by putting an entry into the wiki. Even if engine support is given for determining this by examining a module, it will be far slower than having a declaration in the conf. On phones (low powered devices), such discovery is much too expensive and needs to be cached on a per module basis so that it is not recomputed.<br>
<br>
I still think that it is very needed. I'm getting tired of how such discussions go.<br>
<br>
I'm not at all clear why NoParagraphs was added as a Feature for the frontends to use. I don't remember any discussion of it here. I don't see the need for it. A frontend can examine each and every verse to see if there is paragraphing or other such structural elements that imply paragraphing. I have no intention of using it for the KJV. At least not without community discussion and buy-in.<br>
<br>
How is NoParagraphs any different than NoIntroductions (or Introductions) !!!!!<br>
<br>
In Him,<br>
DM Smith<br>
<br>
On Jun 2, 2013, at 5:47 PM, Chris Little <<a href="mailto:chrislit@crosswire.org" target="_blank">chrislit@crosswire.org</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 6/2/2013 9:23 AM, Chris Burrell wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi<br>
<br>
Some books have Bible introductions. Can I suggest adding a flag to the<br>
conf file to indicate this is the case? In the similar mindset as a<br>
previous post, I'd prefer being able to query the conf file for features<br>
of a particular module rather than having to read part of the module and<br>
hope for that particular book/chapter to have an introduction. A yes/no<br>
flag in the .conf file would be helpful.<br>
<br>
(In particular, I have in mind the book introductions that are part of<br>
the ESV text). But no doubt other modules will also (or in the future<br>
will also) have the same aspects.<br>
<br>
Chris<br>
</blockquote>
I would say no. This doesn't add anything.<br>
<br>
Identifying that a module possesses introductions at some level does not indicate that it possesses all of the introductions at that level. Accordingly, knowing that a module possesses introductions still requires checking for non-empty contents in order to know that a particular introduction is non-empty.<br>
<br>
This is along the lines of the request for a Scope .conf entry, which was already rejected. Whatever solution is used for that case can also be used for introductions.<br>
<br>
--Chris<br>
<br>
<br>
______________________________<u></u>_________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/<u></u>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/<u></u>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/<u></u>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</div></div></blockquote></div><br></div>