From: Julio S. <jul...@gm...> - 2005-07-17 21:04:55
|
I have always found that the existing reports lack all of them something that some other report has. For instance, the Comprehensive Ancestor Report is probably the most complete, but lacks options and does not have a Descendant counterpart. The Detailed Ancestor and Descendant Reports are alright in options, but do not provide events, alternate names or sources. The FTM-style reports have sources, names, etc., but do not give extra information at each level (parents or children of the person studied). I needed a report that had all of it and eenie, meenie,.. I settled for the Detailed Reports. To sum up, I have extended both reports to handle other names, events and sources, mostly after what is done in the FTM reports. These facilities are new options and, since they reuse existing strings, they don't seem to need new translations in the text, but a few strings are needed for the option panel itself. Is it OK for me commit this? On a related topic, I have ported to Graphviz.py the "families as stacks" option from the old RelGraph.py that I have missed since I changed version. However, both the old code and what I have done exhibit a little bit of nonsense in box placement in complex graphs and I want to do some experimentation first. Is it OK to bring this option back as well? Regards, Julio |
From: Alex R. <sh...@gr...> - 2005-07-19 01:48:47
|
Julio, I speak only for myself, so let's maybe wait for other active devels to chime in or maybe discuss it on IRC? Between 5 and 11pm GMT there's a good chance to find Don, Martin, and myself there: channel #gramps at irc.freenode.net That said, here's my opinion: On 07/17/2005 04:04:39 PM, Julio Sanchez wrote: > I have always found that the existing reports lack all of them > something that some other report has. >=20 > For instance, the Comprehensive Ancestor Report is probably the most > complete, but lacks options and does not have a Descendant > counterpart. >=20 > The Detailed Ancestor and Descendant Reports are alright in options, > but do not provide events, alternate names or sources. >=20 > The FTM-style reports have sources, names, etc., but do not give extra > information at each level (parents or children of the person studied). >=20 > I needed a report that had all of it and eenie, meenie,.. I settled > for the Detailed Reports. >=20 > To sum up, I have extended both reports to handle other names, events > and sources, mostly after what is done in the FTM reports. These > facilities are new options and, since they reuse existing strings, > they don't seem to need new translations in the text, but a few > strings are needed for the option panel itself. >=20 > Is it OK for me commit this? I would say yes. As everybody agrees, we have too many reports which do one thing here and the other thing there. It makes sens to everybody that we reduce the number of reports and instead provide more options to the few survivors, to incorporate what is already done in the code into (almost) every report. There's this daunting task of reworking reports -- deciding which to leave in and which to drop, and then porting options existing in the latter to the former ones. Seems like you're doing just that. Maybe we need a single ancestor report, single descendant report, single group report (whatever gets selected by the filter, a section per person), and that's it, for the text reports. The Comprehensive Ancestor and the FTM-style reports are the best candidates to start with. The Detailed reports are old and have a lot of ugly heritage code. I would personally like to get rid of them and to port their unique functions to the FTM-style reports. But for now, if you already improved Detailed ones, let's commit them. Then we can merge them with the FTM ones. That's my take on this. > On a related topic, I have ported to Graphviz.py the "families as > stacks" option from the old RelGraph.py that I have missed since I > changed version. However, both the old code and what I have done > exhibit a little bit of nonsense in box placement in complex graphs > and I want to do some experimentation first. >=20 > Is it OK to bring this option back as well? Definitely! We dropped this option because the code was tangled and hard to follow/debug. If you're doing this, by all means bring it back and fix it. Since the time when we dropped the stack, I had more to do with GraphViz so I guess I should be able to follow it now and help fixing it. Alex P.S. The IRC is a great thing! Whoever is interested in talking things over on gramps-devel, take my word on this: an hour on IRC is more effective that few days of emails (most of the time anyway :-). --=20 Alexander Roitman http://www.gramps-project.org |
From: Julio S. <jul...@gm...> - 2005-07-19 05:16:59
|
Alex, 2005/7/19, Alex Roitman <sh...@gr...>: > Julio, >=20 > I speak only for myself, so let's maybe wait for other active devels > to chime in or maybe discuss it on IRC? Between 5 and 11pm GMT there's > a good chance to find Don, Martin, and myself there: > channel #gramps at irc.freenode.net I'll try. > There's this daunting task of reworking reports -- deciding which to > leave in and which to drop, and then porting options existing in the > latter to the former ones. Seems like you're doing just that. Well, I am not sure I have tackled such a large task, I just have found a way to send my relatives just one report with what I considered the needed info. > Maybe > we need a single ancestor report, single descendant report, single > group report (whatever gets selected by the filter, a section per > person), and that's it, for the text reports. The Comprehensive > Ancestor and the FTM-style reports are the best candidates to start > with. It was difficult to choose. Comprehensive has the best sources handling around because it understands it is dealing with source references, not simply sources, and that those source references contain data that may be useful to show (page and comment, but it leaves out the text, very appropriately, in my opinion). But the space for photos is very intrusive, especially when you don't have photos for 99% of the people and you will never have them because these people predate in centuries the general availability of images that came with the invention of photography. Also the convention it uses for naming generations ("maternal great-great-grandparents", etc.) is confusing: it labels as 'paternal' or 'maternal' in ways that are non-intuitive. All my relatives spot it instantly: "This is wrong!". Problem is I don't have a simple fix. But the real killer was that it has no descendant counterpart and I would have needed to write one. It was a serious candidate, nonetheless. > The Detailed reports are old and have a lot of ugly heritage code. > I would personally like to get rid of them and to port their unique > functions to the FTM-style reports. But for now, if you already improved > Detailed ones, let's commit them. Then we can merge them with the FTM > ones. That's my take on this. I had already fixed a few bugs on the Detailed reports:duplicate children lists in some cases, name presentation when no birth information was present, etc. The FTM reports were right, only the did not have much of an option system to begin with and did not have lists of children and the like.=20 I fact I have taken wholesale large chunks from these reports. > Definitely! We dropped this option because the code was tangled and > hard to follow/debug. If you're doing this, by all means bring it back > and fix it. Since the time when we dropped the stack, I had more to do > with GraphViz so I guess I should be able to follow it now and help > fixing it. It is fixed now, but I am not happy with the presentation of some graphs. My canonical graph is something like: start with a person, find all its blood relatives ('having a common ancestor with...'), add their spouses and their spouses' spouses and, then, make sure the parents of all those spouses are included. A variant is the same, but does not include all blood relatives, only those at N steps from the common branch. Well, the result has always been disappointing, though I had some improvements implemented in the old code. The problem is that everyone knows what such a tree should look like: fathers on the left (or top), mothers on the right (or bottom) and so on for as many generations as there are and, at each level, children in order. So your surname would tend to be placed towards the leftmost (top) side and your mother maternal line on the rightmost (bottom) side and intervening branches placed in their appropriate place. Graphviz does a good job on simple graphs (ascendants, for instance), but on the graphs I use, the result is not good. I think it has to do with its receiving the individual list in random order and that if it had a better ordering in the beginning, individuals would be placed in ranks in roughly the wanted order so that only minor readjustments are needed. As it is now, it seems its algorithms get trapped in some local minimum that is ugly from a genealogical point of view. I also would like some better use of visual cues. I am thinking of taking the N most common lineages (sets of people sharing the same paternal ancestry line, very close to "same surname") and color-code their edges so that lineages can be followed easily. Also, ancestry lines from the start person, I think should be highlighted somehow, maybe through thickening the edges. Regards, Julio |