Re: [Gramps-devel] report options: location, recreation, relative, etc.

[Brian M. <br...@gr...>]

>>  Sorry, my reasoning was that most people would only have one tree, and for

>>  them, there would be very little impact. The report options would just stay
>>  with that one tree. It was raised as a problem by the original reporter. It
>>  also causes problems when things in the options (like person IDs,
>>  references
>>  to notes, or specific filters) are carried across to trees where those
>>  things do not exist (we have had bugs about that). There was a recent
>>  discussion about multiple trees, and it was pointed out that in most cases,
>>  the effort in maintaining one's family history would be reduced by only
>>  maintaining one tree.
>> 
>>  For the very few people who have more than one tree, having settings carry
>>  forward from one tree to another is likely to be a problem, because the
>>  setting would be relevant to the old tree not the new one.
>> 
>>  Of course with any change there are always a few people who are
>>  inconvenienced by the change, and I really appreciate that they will find
>>  it
>>  a nuisance. However, I think that this change will benefit the majority of
>>  the use cases.
>> 
>>  Making a special case for Narrative Web, or adding additional code to copy
>>  forward choices from some previous tree (and there would need to be a
>>  choice
>>  as to which tree was copied from) would make the code much more
>>  complicated,
>>  with little benefit in the majority of cases, just an increase in
>>  maintenance load.
>> 
>>  The new reports options file is automatically created as necessary when
>>  reports are generated from the new tree.
>> 
>>  Again apologies for the inconvenience, but I think there are good reasons
>>  to
>>  make this change.
>>  Regards,
>>  Tim.
> 
> My guess is that you are looking at this too closely from
> the perspective of the narrative web report.  Let it be noted
> that I only very rarely run that report and so I don't claim to
> have a lot of knowledge about it.
> 
> But I have run the other reports a lot, and have looked at
> the options saved away from their use a lot also.  So I disagree
> with you comment about "options" being "carried across" to
> other trees not being relevant.  Very few of the saved-away
> option values are the database-specific ones you are concentrating
> on (person ID, family ID, etc.).  Things like formatting of data,
> which data is included, the structure of how a particular report
> is presented, all of that "generic" information should be preserved.
> 
> You say "The new reports options file is automatically created
> as necessary when reports are generated from the new tree" but
> (I believe) that will be a brand-new file, containing the "default"
> set of options for the report.  It won't have the choices which the
> user has already made, and refined through use, of all the previous
> uses of that report.  That's what I'm interested in preserving.  I
> don't want the user to have to create them each time.  Especially
> as gramps has never operated that way before and so a user has
> come to expect the last-used choices to be present.
> 
> I don't care about the physical location of the file.  I just want the
> history contained in that file to be preserved as changes happen
> to gramps (a new version, a new family tree, etc.).
> 
> Each report (I think) now saves away the choice of a style file the
> user chose the last time that report was run.  Can't you do something
> similar for the narrative web report, have a report option which has
> a filename in it, which would then be some XML file containing the
> specific family tree report?  That would seem to me to carry forward
> the philosophy of how gramps does things.
> 
> More generally, what other ways are there to solve the problem
> you are trying to fix in the narrative web report?
> 
> Philosophically, let me also mention that I don't think it is wise
> for any gramps developer to make assumptions about how the vast
> community of gramps users will use gramps.  In this case whether
> they will have one family tree or not.  I don't like seeing such biases
> and design choices built into gramps, precluding any other ways
> of doing things.  This design choice was not even made a preference,
> so that each user could decide for herself if she wants it done that way.
> 
> What do other developers (or users, if any are reading this) think?

I'm surprised there isn't more interest in this discussion - since it affects us all. 

I personally took a survey of some other desktop applications that i use - and I found that it isn't at all uncommon for some program settings to be saved separately with each file or database. For example, MS Word saves settings about whether hidden text or markup is shown in each .docx file. Also, Gnucash saves settings about saved reports with each database. In my personal use of Gramps, I only have one family tree, so this change doesn't really affect me. But as a user of other applications where I do have multiple files, I see that sometimes it makes sense for some settings to stay with the file.

So I guess I'm OK with the change.

~BM