2013/2/7 Nick Hall <nick__hall@hotmail.com>
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

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



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.
Gramps-devel mailing list