It would be nice if an icon or column indicating a source could be added to the indi lists (for births and deaths), and to the family list to indicate a source for the marriage. Would this significantly add to the time needed to generate lists?
The family lists (like the indi lists) can take its information from a number of records. For example, if you have
1 CHR
2 PLAC somehwere
1 BIRT
2 DATE whenever
then it uses the date from one and the place from the other.
With marriages, similar logic applies (for MARR and MARB events). However, we can still take data from *two* MARR events. e.g.
1 MARR
2 DATE date
1 MARR
2 PLAC place
Then there are other cases where a couple married more than once. Either with or without an intervening divorce.
Now, since none/some/all of these events may have a source, you don't have a simple "is sourced" indicator. Furthermore, for performance, these values are extracted from the raw gedcom, not via the events class, so we would have to go back to the gedcom, search for the correctponding event, then look for a source. So, to answer the question
<<Would this significantly add to the time needed to generate lists?>>
I think that with the current design, the answer is yes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are just looking for unsourced facts, I wrote a block that lists these.
The family lists (like the indi lists) can take its information from a number of records. For example, if you have
1 CHR
2 PLAC somehwere
1 BIRT
2 DATE whenever
then it uses the date from one and the place from the other.
With marriages, similar logic applies (for MARR and MARB events). However, we can still take data from *two* MARR events. e.g.
1 MARR
2 DATE date
1 MARR
2 PLAC place
Then there are other cases where a couple married more than once. Either with or without an intervening divorce.
Now, since none/some/all of these events may have a source, you don't have a simple "is sourced" indicator. Furthermore, for performance, these values are extracted from the raw gedcom, not via the events class, so we would have to go back to the gedcom, search for the correctponding event, then look for a source. So, to answer the question
<<Would this significantly add to the time needed to generate lists?>>
I think that with the current design, the answer is yes.