Quantcast

report options: location, recreation, relative, etc.

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

report options: location, recreation, relative, etc.

Paul Franklin-5
Recently, apparently in connection with this bug:
www.gramps-project.org/bugs/view.php?id=3968#c27255
a developer decided to move the report options file -- "in
gramps34/gramps40/trunk revisions 21304/21305/21306"
-- and I would like to see this discussed a little first.

I don't think such a major change in the way gramps
operates qualifies as a bug fix.  Personally, I don't want
to have to copy around my report_options file whenever
I create a new database (family tree).  I want my report
options to remain as they are, for every family tree I create.

If the narrated web report is different then perhaps it can
be somehow given special treatment.  But I don't think
changing the way all report options are stored is the way
it should be fixed.

Will the new report options file be recreated whenever a
new tree is created?  Will it be "seeded" with the existing
choices the user has accumulated?  That doesn't have to
happen now because the same results happen automatically.

And so on.

Thanks.

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Tim Lyons
Administrator
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Paul Franklin-5
On 2/5/13, Tim Lyons <[hidden email]> wrote:

> 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?

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Brian Matherly
>>  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


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Paul Franklin-5
In reply to this post by Paul Franklin-5
At the top level of a user directory (typically ~/.gramps) I
observe a file called tool_options.xml -- and I wonder if in
your proposed system you plan to also move that one into the
database-specific directory?

What about all the "style" files which are there too -
things like ancestor_chart.xml and ancestor_report.xml?

How about the file which contains the Book Report books
(books.xml)?  Do you argue that it is database-specific too?

What about recent-files-gramps.xml?  Surely that is
database-specific also, by your argument?

Let me provide another use-case.  Here is an extract from my
report_options.xml file.  It is for one option name/value
setting, for one report:

<pre>
  <option name="spouse_disp" value="" length="4">
    <listitem number="0" value="$n(f l s)"/>
    <listitem number="1" value="{b. {$b(mmm&lt; &gt;d&lt;, &gt;yyyy)}{ ($B)}}"/>
    <listitem number="2" value="{m. {$m(mmm&lt; &gt;d&lt;, &gt;yyyy)}{ ($M)}}"/>
    <listitem number="3" value="{d. {$d(mmm&lt; &gt;d&lt;, &gt;yyyy)}{ ($D)}}"/>
  </option>
</pre>

It controls what appears in every instance of one type of
box (for every spouse) in that report, and you can probably
guess that it took me quite a while to evolve.  It continues
to evolve and change, as I make subtle changes over time.

So then, when I am entering data into my family tree, I
sometimes put in data which the family does not want known
to the world.  One family doesn't want the birthdates of
their children known for instance.  Another family doesn't
want their marriage date known (since it was before the
divorce date of a previous marriage).  I mark those pieces
of data with the "private" icon/flag in gramps, as I am
entering them.

So then periodically, after I've accumulated enough changes,
I need to generate another family-tree booklet and send it
out.  I do that by exporting the family tree (as gramps XML)
with the "exclude private things" box checked.  I then
import that XML as a new family tree, which then contains a
subset of the master tree, for that branch of that family.

Up to now I could just run that report and my saved-away
values -- such as the formatting information above -- would
automatically be used.

If I understand what you have done, what will happen now is
that I will have to either 1) manually recreate every such
option, for every such report, or 2) manually copy the
report_options.xml from some database directory -- and how
will I know which one, since they are cleverly called such
things as "4fd8a997" and "4ff9b649" (so I will need to do a
"gramps -L" every time) -- to some other database directory.

Since you remember the thread where how many family trees a
user should have was discussed, I'm sure you also remember
the many postings (and bug tracker comments) over the years,
such as the very recent one, where some user asks (more or
less) "where is my configuration information"?  You are now
proposing that every one of them who wants to do something
like this must know that, as well as such arcane information
as how databases are stored.  When even some developers
don't know (e.g. for Windows if a person is a linux user).
And when many gramps users have no idea how to find files or
directories on their own computer.

It still seems to me you could have instead implemented a
narrative web XML file.  You could have made it similar to
the books.xml file, a separate file which can contain an
infinite number of /database-specific/ reports, with each
stanza having its own set of values, even if the names are
the same.  Under such a system one file would contain every
one of the nuances you care about, all keyed under some sort
of discriminator (as books.xml has the "book" name at the
start of each stanza -- with the database on the same line).

I still think that what you have done is a bad idea.

The narrative web report is as much of a special-case report
as the book report is.  Why not acknowledge that fact and
give it its own control file?  Then you can do whatever you
want with it.

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Doug
In reply to this post by Brian Matherly
On 07/02/13 13:59, Brian Matherly wrote:

>>>   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

Speaking as an ordinary user I maintained two complete
separate family trees for several years, being convinced
they were connected but unable to find the evidence, until
it eventually turned up. Now I often have several versions
of the main tree running together with bits of trees to work
on that I think might be relevant. As far as reports are
concerned I use Navweb a lot for distributing tailored trees
to selected groups of relatives - it's not clear to me how
much of a hindrance the proposed changes will be.

Doug


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

John Ralls-2
In reply to this post by Brian Matherly

On Feb 7, 2013, at 5:59 AM, Brian Matherly <[hidden email]> wrote:

>>> 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.
>

Gnucash does not keep state information, preferences or otherwise, in the accounts file. Some of it is kept per database (though not custom reports), but it's all in ~/.gnucash or GConf.

I don't think that it's a good idea for Gramps to put preference data in the database, either, and I particularly think that it's a bad idea to put anything not controlled by bdb in the database directory. Bdb is really finicky about its environment. If it's desirable to have per-database preferences, create a suitable structure in ~/.gramps instead.

I also agree with Paul that this is a major change to Gramps's behavior and so has no business being backported to a stable branch. That's reinforced by the fact that the bug in question is a feature request.

Project-management issues aside, I recognize that there are clearly use cases supporting both sides: Some users will want to
use the same report settings across all of their databases, others will want different settings per database, and some will want
a bit of each: Some things apply across the board and others are customized per database. Perhaps we could get there with a two-level structure: A defaults settings file and a set of per-database override files.

Regards,
John Ralls


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Paul Franklin-5
> ... Perhaps we could get there with a two-level structure: A
> defaults settings file and a set of per-database override files.

Note that the book report is sort of this way, with the last-run
information of the book report kept in the report_options.xml
file and all the details on all the sub-choices in the books.xml
one.

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Nick Hall-6
In reply to this post by John Ralls-2
On 07/02/13 16:14, John Ralls wrote:
> I don't think that it's a good idea for Gramps to put preference data in the database, either, and I particularly think that it's a bad idea to put anything not controlled by bdb in the database directory. Bdb is really finicky about its environment. If it's desirable to have per-database preferences, create a suitable structure in ~/.gramps instead.

I agree, I don't think that we should be putting preference data in the
database.


>
> I also agree with Paul that this is a major change to Gramps's behavior and so has no business being backported to a stable branch. That's reinforced by the fact that the bug in question is a feature request.

Correct.  This is a feature request, not a bug fix.  We shouldn't be
introducing it into a stable branch.


>
> Project-management issues aside, I recognize that there are clearly use cases supporting both sides: Some users will want to
> use the same report settings across all of their databases, others will want different settings per database, and some will want
> a bit of each: Some things apply across the board and others are customized per database. Perhaps we could get there with a two-level structure: A defaults settings file and a set of per-database override files.

I don't think we want per database report settings.  A two-level
structure would be flexible, but also more complicated.

Nick.


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Benny Malengier



2013/2/7 Nick Hall <[hidden email]>
On 07/02/13 16:14, John Ralls wrote:
> I don't think that it's a good idea for Gramps to put preference data in the database, either, and I particularly think that it's a bad idea to put anything not controlled by bdb in the database directory. Bdb is really finicky about its environment. If it's desirable to have per-database preferences, create a suitable structure in ~/.gramps instead.

I agree, I don't think that we should be putting preference data in the
database.


>
> I also agree with Paul that this is a major change to Gramps's behavior and so has no business being backported to a stable branch. That's reinforced by the fact that the bug in question is a feature request.

Correct.  This is a feature request, not a bug fix.  We shouldn't be
introducing it into a stable branch.


>
> Project-management issues aside, I recognize that there are clearly use cases supporting both sides: Some users will want to
> use the same report settings across all of their databases, others will want different settings per database, and some will want
> a bit of each: Some things apply across the board and others are customized per database. Perhaps we could get there with a two-level structure: A defaults settings file and a set of per-database override files.

I don't think we want per database report settings.  A two-level
structure would be flexible, but also more complicated.


I agree with the main sentiment of Nick.

As to how to implement it, personally I find changing  person ID or filter between family trees easier than needing to copy settings over, so one file for all family trees has my preference.

However, there are clear problems with this, specifically on person ID. I have always found it annoying we cannot store/load some settings. The fact that we only have the latest settings means you sometimes need to recreate something of some time ago, and it always takes a lot of time to do that.
A defaults setting and a per database override is hence one options, saving/loading previous settings is another way around this issue, which IMO is more general. One could be default, one could be latest, and then user can create others. Being able to return to default settings would be a great thing for many users.

Finally, I agree with Paul, it is very annoying if these things pop up after a release and you find yourself not knowing about them.
So, I would be for removing this, and reimplementing in a different way, acceptable for every use-case. Removing because I would not want it to hold up future releases.

Benny


Nick.


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Tim Lyons
Administrator
In reply to this post by Paul Franklin-5
I have reverted the change for moving reports_options.xml in gramps34/gramps40/trunk rev 21322/21323/21324.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Tim Lyons
Administrator
In reply to this post by John Ralls-2
John Ralls-2 wrote
I particularly think that it's a bad idea to put anything not controlled by bdb in the database directory. Bdb is really finicky about its environment. If it's desirable to have per-database preferences, create a suitable structure in ~/.gramps instead.
The Family Tree name and the bdbversion are already stored in the database directory.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Tim Lyons
Administrator
In reply to this post by Paul Franklin-5
In the interests of transparency:

I made two other changes, related to per-family tree options, which do not seem to have been mentioned in this thread:

(1) I changed the default filename for reports to contain the family tree name followed by an abbreviation of the report name. This default is only used if the user has not already chosen a specific name for the report. Having reverted the movement of the report-options file, this means that if you choose a specific name for a report for ANY database, then that name will be used for the output file for that report for all databases. Hence, this will only affect users who have not chosen a file name for a report. Again, I think this is helpful to separate out the same report for different family trees.

(2) I implemented the paths.website-directory (in gramps.ini) in line with paths.report-directory. paths.website-directory was declared, but not set and used properly. These two directories are ONLY used when the user does no specify a particular name for a report. If a name is specified by the user, then that full pathname was and is always used for the report. paths.website-directory now works exactly the same as paths.report-directory. It is only altered and used when the last element in the path is the default name.

I don't think these changes relate to the examples discussed in this thread, and I think that they will affect very few users. Since they don't impact the database directory at all - they only relate to data that is already in the various options files, do you want me to revert these too?

I would certainly like to keep these changes, because whenever there is more than one family tree, it becomes very difficult to remember which file contains which report, and it is all too easy to accidentally overwrite a report with another report for a different tree.

regards,
Tim.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Benny Malengier



2013/2/8 Tim Lyons <[hidden email]>
In the interests of transparency:

I made two other changes, related to per-family tree options, which do not
seem to have been mentioned in this thread:

(1) I changed the default filename for reports to contain the family tree
name followed by an abbreviation of the report name. This default is only
used if the user has not already chosen a specific name for the report.
Having reverted the movement of the report-options file, this means that if
you choose a specific name for a report for ANY database, then that name
will be used for the output file for that report for all databases. Hence,
this will only affect users who have not chosen a file name for a report.
Again, I think this is helpful to separate out the same report for different
family trees.

Ok for me. I suppose you now store a name in two parts, a family-tree-name part and the non-family-tree name part.
If second is given and not first, you use second, if first and second is given, you replace first with the current family tree name?
Otherwise I can't think of a way to code that logically correct :-)


(2) I implemented the paths.website-directory (in gramps.ini) in line with
paths.report-directory. paths.website-directory was declared, but not set
and used properly. These two directories are ONLY used when the user does no
specify a particular name for a report. If a name is specified by the user,
then that full pathname was and is always used for the report.
paths.website-directory now works exactly the same as
paths.report-directory. It is only altered and used when the last element in
the path is the default name.

I would have to try this, but does not seem an issue.

I don't think these changes relate to the examples discussed in this thread,
and I think that they will affect very few users. Since they don't impact
the database directory at all - they only relate to data that is already in
the various options files, do you want me to revert these too?

For me not. However, these changes in gramps34 might create a bugs on release of point upgrade there. For narweb, because we decided to upgrade in gramps34 also, that is not a problem. For the rest, you should be careful with features in gramps34. At a minimum it will mean you need to be available after a release.

Benny

I would certainly like to keep these changes, because whenever there is more
than one family tree, it becomes very difficult to remember which file
contains which report, and it is all too easy to accidentally overwrite a
report with another report for a different tree.

regards,
Tim.



--
View this message in context: http://gramps.1791082.n4.nabble.com/report-options-location-recreation-relative-etc-tp4658582p4658667.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Paul Franklin-5
In reply to this post by Tim Lyons
On 2/8/13, Tim Lyons <[hidden email]> wrote:

> (1) I changed the default filename for reports to contain the family tree
> name followed by an abbreviation of the report name. ...

In the process of doing that, the functionality I added for
www.gramps-project.org/bugs/view.php?id=5900 (in trunk
19988) was removed.

I wonder if it was intentional or inadvertent?  If the new default
name is going to be as you have made it, I really want to be able
to set my own report name and have it be remembered, instead.

I am referring to the first two lines in:

<pre>
-            if self.options.get_output():
-                base = os.path.basename(self.options.get_output())
-            else:
-                base = "%s.%s" % (self.report_name, ext)
+            default_name = self.dbname + "_" + \
+                        "".join(x[0].upper() for x in self.raw_name.split("_"))
+            base = "%s.%s" % (default_name, ext)
</pre>

Thanks.

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: report options: location, recreation, relative, etc.

Nick Hall-6
In reply to this post by Tim Lyons
On 08/02/13 17:48, Tim Lyons wrote:
> (1) I changed the default filename for reports to contain the family tree
> name followed by an abbreviation of the report name. This default is only
> used if the user has not already chosen a specific name for the report.
> Having reverted the movement of the report-options file, this means that if
> you choose a specific name for a report for ANY database, then that name
> will be used for the output file for that report for all databases. Hence,
> this will only affect users who have not chosen a file name for a report.
> Again, I think this is helpful to separate out the same report for different
> family trees.

I don't like using the short 2 or three letter abbreviation here. It is
only used for styles at the moment.  The previous filename was much more
obvious.

Including the database name in the default filename is a good idea, but
why is it included in v3.4?  This is an enhancement rather than a bug fix.


>
> (2) I implemented the paths.website-directory (in gramps.ini) in line with
> paths.report-directory. paths.website-directory was declared, but not set
> and used properly. These two directories are ONLY used when the user does no
> specify a particular name for a report. If a name is specified by the user,
> then that full pathname was and is always used for the report.
> paths.website-directory now works exactly the same as
> paths.report-directory. It is only altered and used when the last element in
> the path is the default name.

I don't know this code, but it seems closely related to the narrative
web tidy-up.  It seems sensible to include this with the other narrative
web changes.

Nick.


------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Loading...