From: Paul F. <pf....@gm...> - 2013-02-07 15:10:15
|
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< >d<, >yyyy)}{ ($B)}}"/> <listitem number="2" value="{m. {$m(mmm< >d<, >yyyy)}{ ($M)}}"/> <listitem number="3" value="{d. {$d(mmm< >d<, >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. |