[sword-devel] Strange option filters

[Jaak Ristioja]

Thank you, but unfortunately this only helps me a small bit.

If these filters are never meant to be presented to the users as "option
filters", why do these still inherit from SWOptionFilter? Note that
GreekLexAttribs and PapyriPlain are inserted into SWMgr::optionFilters
by SWMgr::init(). Why is this needed?

Looking at SWMgr code using SWMgr::optionFilters it seems as if some of
those methods are supposed to handle filters like GreekLexAttribs and
PapyriPlain in SWMgr::optionFilters whereas other methods are meant to
ignore such SWMgr::optionFilters elements.

I'm very confused by the handling of option filters in SWMgr. Are
GreekLexAttribs and PapyriPlain meant to belong to some class of
"optional filters" (i.e. toggled by a module config) instead of being
"option filters" (i.e. a class of filters presenting options to the
user) whereas some SWMgr code is supposed to handle both of these classes?

I'm sorry if I'm asking stupid questions because I think I don't yet
fully understand how filters are supposed to work in Sword.

J

On 01.12.2016 17:13, Troy A. Griffitts wrote:
> Not looking at the code, but quickly I can comment that the PapyriPlain
> filter is used with the Duke Databank of Papyri as a LocalOptionFilter
> (not added to the list of global options presented to the user to
> toggle, but can still be toggled programmatically).  Hope this helps.
> 
> Troy
> 
> 
> On 11/30/2016 03:03 PM, Jaak Ristioja wrote:
>> On 27.10.2016 22:54, Jaak Ristioja wrote:
>>> Hi!
>>>
>>> While refactoring some option filters code for Sword++ I found two
>>> strange option filters, GreekLexAttribs and PapyriPlain which inherit
>>> from SWOptionFilter and use SWOptionFilter::SWOptionFilter(). This
>>> behavior was introduced in SVN 1864:
>>>
>>>      commit bdc81675088ca687338ca29acef6c384710b6bcf
>>>      Author: scribe <scribe at bcd7d363-81e1-0310-97ec-a550e20fc99c>
>>>      Date:   Sun Nov 20 06:06:40 2005 +0000
>>>
>>>                  Cleaned up headers to remove unnecessary includes
>>>
>>>      git-svn-id: https://crosswire.org/svn/sword/trunk@1864
>>> bcd7d363-81e1-0310-97ec-a550e20fc99c
>>>
>>> Neither of those classes override any of the SWOptionFilter methods for
>>> options, hence the effects of SWOptionFilter::SWOptionFilter() are
>>> permanent for instances of these classes. This means that
>>> getOptionName() returns "" for both of these classes. This looks as if
>>> it could cause problems for SWMgr which seems to rely on these being
>>> unique strings for each class (e.g. in SWMgr::AddGlobalOptions). So its
>>> rather confusing.
>>>
>>> Some SWMgr methods test whether getOptionName() returns NULL. I couldn't
>>> find any conclusive hints in Sword source code to describe the rationale
>>> of it returning NULL. None of the Sword classes themselves seem to
>>> return NULL themselves. So the only possible way for getOptionName() to
>>> return NULL is for some child class overriding getOptionName() or
>>> overwriting that protected field. Before SVN 1864 these virtual methods
>>> were also part of SWFilter and their defaults returned NULL (well, 0).
>>> Can someone please enlighten me about this code?
>>>
>>> Thanks!
>>>
>>> Many blessings,
>>> Jaak
>>>
>>> PS: Should these two classes actually be simple On/Off-style option
>>> filters and properly call the other SWOptionFilter constructor?
>> Bump.
>>
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page