Re: [Gramps-devel] Re : Source types and source management

[Peter L. <pet...@te...>]

Are there anything common usage of sources between different countries? For example I never use 
census as my source in Sweden as they more or less a copy of the church archives for a specific 
date. But of course if I'm looking for my emigrants in USA, then I would need census help.

Shall we document the fundamental source or shall we document the digitized Internet accessible 
version of it?

I think this will become very complicated if we are going to make this "universal", to handle many 
types of sources "worldwide". It needs at least many new "sources_xx.py" for many countries.

/Peter

> Ah yes. The certificate idea:
>
> http://www.gramps-project.org/wiki/index.php?title=GEPS_012:_Ecosystem_defi
>nition#Certificates
>
> It's really just one special case of what I'm talking about.  Sources
> are of course very broad in format, readability, reliability, etc.
> I'd like to see a way to easily manage these different types.  So if
> you start working on a census event, a box pops up asking "which one?"
> where we build up sets of custom entry forms for the censi that we
> know about, _and_ do it in such a way so that a new user with a (to
> us) unknown census can easily add support for that one.
>
> If it's a publication, we might have dialogs for newspapers (you need
> name, publisher, year, volume, section, page, column, etc.), magazines
> (similar to newspapers but probably no section or column),
> multi-volume works, privately-published genealogies, etc, etc,
>
> If it's a birth, death, marriage, military etc. certificate, there
> would be separate dialogs for each type, possibly customized by
> jurisdiction.  Which brings up another thought:
>
> The dialogs should be dynamic and respond to data as entered.  So if I
> say "census!" the start typing "Canada" it would prompt me for the
> available censi (1851/2, 1861, 1871, 1881, 1891, 1901, 1906, 1911,
> 1916) and have the smarts to know if there are multiple schedules
> available (e.g. for 1901).  If I get to province and start typing
> "Ontario" it could prompt me for the county (the list may differ by
> date).  Note: You may not want to do a whole country this way since
> the data would be large if you drilled down to the township/city
> level.
>
> However we do it (and if we do it), I would like to see a system that
> is easy to understand and easy to extend.  Also, the system would not
> be just for data entry but also for display.  So if I entered a census
> source this way, the next time I went to look at it the same dialog
> would be there, with the data I had already filled in.
>
> On Fri, Dec 18, 2009 at 10:07 AM, Benny Malengier
>
> <ben...@gm...> wrote:
> > There are some things I want to note here:
> >
> > 1/any developer changing things in the source system of Gramps must be
> > very careful not to change things as he uses sources. Many people use
> > the source system in different ways. This does not mean things cannot
> > change, only that they must be planned and designed carefully. I think
> > things can improve a lot, the question is only how to best achieve
> > this.
> >
> > 2/we have dynamic building of the filter rules, and dynamic binding of
> > the report plugin options. I think this is a better system than glade
> > files. So, a set of predefined widgets that can be reused, a way to
> > set the layout from these elements, and a framework into which to do
> > this. The suggestion of Gerals looks to me like another angle to the
> > certificate approach I advocated instead of the data entry gramplets.
> > In that view the present data entry gramplets can be seen as test
> > cases for what such a certificate approach must make more easy.
> >
> > Benny
> >
> > 2009/12/17 Nick Hall <nic...@ho...>:
> >> Jerome,
> >>
> >> Thanks for the links.
> >>
> >> The date on the source reference is: "The date that this event data was
> >> entered into the original source document."
> >>
> >> This seems to me to be most appropriate for registers and ledgers which
> >> are continuously being added to, not to published documents.  In Geralds
> >> examples, the census had a date but the entry for his ancestor was made
> >> on a different date.  This is a good use of this field.  The other
> >> example of a periodical also works quite well; the date of publication
> >> for the source spans many months or years, but we are interested in one
> >> issue for a given date.
> >>
> >> I think that one of the problems for new users is knowing what to use
> >> certain fields for.  The source type suggestion would help with this.
> >>
> >> For a register the date could be described as "Entry Date", for a census
> >> it could be "Date Recorded", and for a periodical it could be "Issue
> >> Date".
> >>
> >> Nick.
> >>
> >> jerome wrote:
> >>> When I started to use Gramps, I set the date of my search on the date
> >>> field (i.e find this event/sourceref on 2007, an other person/sourceref
> >>> on 2008 for the same source, etc ...)
> >>>
> >>> Then with "Bibliography in reports (display of source information)" -
> >>> mailing list (2007), I understand that we should rather use this field
> >>> for the date written into the source, or the time log if source =
> >>> someone).
> >>>
> >>> Now, I add this information on Publication information (Source object)
> >>> ... (but could be source title) Just because I try to avoid secondary
> >>> objects. Primary object with less secondary "levels" as possible
> >>> because informations are also displayed on views and could be filtered,
> >>> etc ...
> >>>
> >>>> So I might say that I was married 5 April 1975 and refer to a source
> >>>> with a date of 10 Dec 1980, when the source was published.  Is that
> >>>> what you mean ?
> >>>
> >>> Yes ! It is the date on source reference, when the event is highlighted
> >>> on the source.
> >>>
> >>> Note, I also find the date of search (when we find event/person/family
> >>> on the source), not false ...
> >>>
> >>> But Benny highlights the way to use date field on source reference :
> >>>
> >>> "As I understand it, GEDCOM date in sourceref means to do the
> >>> following: A source is ag: baptize acts 1902-1912. Then, in a baptize
> >>> record (same for marriage, death), the individual acts are numbered
> >>> according to date, so: "1910-05-02, baptized John, son of ....." So the
> >>> date is the log date of the event hapening as written down in the
> >>> source. So date is there to allow you to find the birth record in the
> >>> source, the same as page helps you to find the relevant section in a
> >>> book (the old records don't have page numbers and numbering is often
> >>> something added by present day researchers, not by the person who wrote
> >>> the record). So date and page in sourceref serve the same purpose." ---
> >>> Benny (archives May 21, 2007 - Bibliography in reports)
> >>>
> >>>
> >>> Note, Gramps was just following Gedcom spec !
> >>> http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#SOU
> >>>RCE_CITATION
> >>> http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#WHE
> >>>RE_WITHIN_SOURCE
> >>> http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#ENT
> >>>RY_RECORDING_DATE
> >>> http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#SOU
> >>>RCE_PUBLICATION_FACTS
> >>>
> >>>
> >>> Jérôme
> >>>
> >>> --- En date de : Jeu 17.12.09, Gerald Britton <ger...@gm...> a écrit :
> >>>> De: Gerald Britton <ger...@gm...>
> >>>> Objet: Re: Re : [Gramps-devel] Source types and source management
> >>>> À: "jerome" <rom...@ya...>
> >>>> Cc: "Nick Hall" <nic...@ho...>, "gramps-devel"
> >>>> <gra...@li...> Date: Jeudi 17 Décembre 2009,
> >>>> 18h16
> >>>> I'm not sure I understand you
> >>>> properly Jerome, but I think you are
> >>>> highlighting the difference between an event (such as a
> >>>> marriage) and
> >>>> when a source record became available.  So I might say
> >>>> that I was
> >>>> married 5 April 1975 and refer to a source with a date of
> >>>> 10 Dec 1980,
> >>>> when the source was published.  Is that what you
> >>>> mean?
> >>>>
> >>>> On Thu, Dec 17, 2009 at 12:13 PM, jerome <rom...@ya...>
> >>>>
> >>>> wrote:
> >>>>>> What is the Date field for? Again in most cases
> >>>>
> >>>> the date
> >>>>
> >>>>>> will apply to
> >>>>>> the source: a publication date or a census date
> >>>>
> >>>> for
> >>>>
> >>>>>> example. Where it is
> >>>>>> applicable for a reference, such as for a
> >>>>
> >>>> marriage
> >>>>
> >>>>>> register, I tend to
> >>>>>> put the date on the event only and don't put a
> >>>>
> >>>> copy in the
> >>>>
> >>>>>> SourceRef.
> >>>>>
> >>>>> Date on a reference seems to be like a time log !
> >>>>
> >>>> [1][2]
> >>>>
> >>>>> ie. event (with date), which is noted on sources could
> >>>>
> >>>> happen few or many days/months/years before the source has
> >>>> been written (reported event).
> >>>>
> >>>>> For the source type, we could also have a level
> >>>>
> >>>> question !
> >>>>
> >>>>> http://www.gramps-project.org/wiki/index.php?title=Sources#Definition
> >>>>>
> >>>>>
> >>>>> [1]
> >>>>> http://old.nabble.com/Bibliography-in-reports-(display-of-source-info
> >>>>>rmation)-p10702537.html (sorry cannot find the exact post, but Benny
> >>>>> or Brian
> >>>>
> >>>> has given the correct/logical answer : time log)
> >>>>
> >>>>> [2]
> >>>>> http://old.nabble.com/Date-field-on-SourceRef-to12047334.html#a120473
> >>>>>34
> >>>>>
> >>>>>
> >>>>> Jérôme R.
> >>>>>
> >>>>>
> >>>>> --- En date de : Jeu 17.12.09, Nick Hall <nic...@ho...>
> >>>>
> >>>> a écrit :
> >>>>>> De: Nick Hall <nic...@ho...>
> >>>>>> Objet: [Gramps-devel]  Source types and source
> >>>>
> >>>> management
> >>>>
> >>>>>> À: "Gerald Britton" <ger...@gm...>
> >>>>>> Cc: "gramps-devel" <gra...@li...>
> >>>>>> Date: Jeudi 17 Décembre 2009, 17h26
> >>>>>> This is a good idea.
> >>>>>>
> >>>>>> A source type could customise the input fields for
> >>>>
> >>>> both the
> >>>>
> >>>>>> Source and
> >>>>>> SourceRef records.
> >>>>>>
> >>>>>> For example an English Census would need the
> >>>>
> >>>> following
> >>>>
> >>>>>> fields in SourceRef:
> >>>>>>
> >>>>>> * PRO Reference, Piece, Folio, Page
> >>>>>>
> >>>>>> and in the Source record it would really just
> >>>>
> >>>> need:
> >>>>>> * Title, Publisher, Date
> >>>>>>
> >>>>>> Whereas a book probably only needs one field in
> >>>>
> >>>> SourceRef:
> >>>>>> * Page
> >>>>>>
> >>>>>> but a few in the Source record:
> >>>>>>
> >>>>>> * Title, Author, Publisher, Date, ISBN Number
> >>>>>>
> >>>>>>
> >>>>>> I think that the extension to SourceRef would
> >>>>
> >>>> probably be
> >>>>
> >>>>>> the most
> >>>>>> useful benefit. As the fields are likely to be
> >>>>
> >>>> text only
> >>>>
> >>>>>> all that is
> >>>>>> really needed to define a source type is a list of
> >>>>
> >>>> field
> >>>>
> >>>>>> names. The
> >>>>>> SourceRef fields could then be built by a script
> >>>>
> >>>> rather
> >>>>
> >>>>>> than having to
> >>>>>> supply a glade file. The existing database field
> >>>>
> >>>> could be
> >>>>
> >>>>>> used to store
> >>>>>> the data, but as a list rather than a string.
> >>>>>>
> >>>>>> A couple of unrelated comments -
> >>>>>>
> >>>>>> I don't use the Confidence field, but I would use
> >>>>
> >>>> it if I
> >>>>
> >>>>>> could supply
> >>>>>> the confidence of a source as a whole rather than
> >>>>
> >>>> for each
> >>>>
> >>>>>> reference
> >>>>>> individually.
> >>>>>>
> >>>>>> What is the Date field for? Again in most cases
> >>>>
> >>>> the date
> >>>>
> >>>>>> will apply to
> >>>>>> the source: a publication date or a census date
> >>>>
> >>>> for
> >>>>
> >>>>>> example. Where it is
> >>>>>> applicable for a reference, such as for a
> >>>>
> >>>> marriage
> >>>>
> >>>>>> register, I tend to
> >>>>>> put the date on the event only and don't put a
> >>>>
> >>>> copy in the
> >>>>
> >>>>>> SourceRef.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>>
> >>>>>> Nick.
> >>>>>>
> >>>>>> Gerald Britton wrote:
> >>>>>>> Back in June, John (jh...@ea...)
> >>>>>>
> >>>>>> posed a question about using
> >>>>>>
> >>>>>>> the expanded approach to sources espoused by
> >>>>
> >>>> Elizabeth
> >>>>
> >>>>>> Shown Millls in
> >>>>>>
> >>>>>>> her books "Evidence!" and "Evidence
> >>>>
> >>>> Explained."
> >>>>
> >>>>>> At the time, I was
> >>>>>>
> >>>>>>> skeptical as I was not familiar with the
> >>>>
> >>>> author or
> >>>>
> >>>>>> that approach.
> >>>>>>
> >>>>>>> Since then, I have familiarized myself with
> >>>>
> >>>> her work
> >>>>
> >>>>>> and become very
> >>>>>>
> >>>>>>> receptive to the concepts contained therein.
> >>>>>>>
> >>>>>>> The basic idea is, that "source" is too
> >>>>
> >>>> general and
> >>>>
> >>>>>> one needs a way to
> >>>>>>
> >>>>>>> categorize sources.  For example, if the
> >>>>
> >>>> source
> >>>>
> >>>>>> is a census, you will
> >>>>>>
> >>>>>>> want to capture data like the year of the
> >>>>
> >>>> census, the
> >>>>
> >>>>>> state, city,
> >>>>>>
> >>>>>>> parish (or other administrative district)
> >>>>
> >>>> page number,
> >>>>
> >>>>>> household,
> >>>>>>
> >>>>>>> family number etc.  On the other hand, if
> >>>>
> >>>> the
> >>>>
> >>>>>> source is a published
> >>>>>>
> >>>>>>> pedigree in a book, you will want the title
> >>>>
> >>>> and author
> >>>>
> >>>>>> of the book,
> >>>>>>
> >>>>>>> (possibly) a volume number, the page number
> >>>>
> >>>> and
> >>>>
> >>>>>> publisher.  These two
> >>>>>>
> >>>>>>> source categories call for different sorts of
> >>>>
> >>>> data
> >>>>
> >>>>>> capture.
> >>>>>>
> >>>>>>> Several commercial programs have adopted this
> >>>>
> >>>> approach
> >>>>
> >>>>>> and built
> >>>>>>
> >>>>>>> templates for source data by category.
> >>>>
> >>>> This
> >>>>
> >>>>>> makes is easy to
> >>>>>>
> >>>>>>> consistently capture the right data for a
> >>>>
> >>>> given type
> >>>>
> >>>>>> of source.  I've
> >>>>>>
> >>>>>>> been wondering for a while if we should do
> >>>>
> >>>> something
> >>>>
> >>>>>> similar in
> >>>>>>
> >>>>>>> gramps.  It would work something like this:
> >>>>>>>
> >>>>>>> 1. When you want to add a source, the first
> >>>>
> >>>> thing you
> >>>>
> >>>>>> would do is
> >>>>>>
> >>>>>>> select a source type from a drop-down list
> >>>>
> >>>> (it would
> >>>>
> >>>>>> default to
> >>>>>>
> >>>>>>> "Unknown" which would be similar to what we
> >>>>
> >>>> have in
> >>>>
> >>>>>> place today).
> >>>>>>
> >>>>>>> 2. Once a source type is selected, gramps
> >>>>
> >>>> would
> >>>>
> >>>>>> present a dialog
> >>>>>>
> >>>>>>> crafted specifically for that source type
> >>>>
> >>>> which the
> >>>>
> >>>>>> user can then
> >>>>>>
> >>>>>>> easily fill in.
> >>>>>>>
> >>>>>>> 3. The data would be stored in a structured
> >>>>
> >>>> form in
> >>>>
> >>>>>> the database which
> >>>>>>
> >>>>>>> can be accessed for reports and future edits
> >>>>>>>
> >>>>>>> 4. The source types would be represented by
> >>>>
> >>>> glade
> >>>>
> >>>>>> dialogs (stored as
> >>>>>>
> >>>>>>> XML).  The type of the source would be
> >>>>
> >>>> stored in
> >>>>
> >>>>>> the glade file and in
> >>>>>>
> >>>>>>> a special directory.
> >>>>>>>
> >>>>>>> 5. At startup, gramps would read the source
> >>>>
> >>>> types
> >>>>
> >>>>>> directory and build
> >>>>>>
> >>>>>>> a dictionary mapping the source type to the
> >>>>
> >>>> glade
> >>>>
> >>>>>> file, for use when
> >>>>>>
> >>>>>>> actually displaying or editing the source
> >>>>
> >>>> material.
> >>>>
> >>>>>>> With glade files stored in a special
> >>>>
> >>>> directory for
> >>>>
> >>>>>> source types, it
> >>>>>>
> >>>>>>> will be easy to add new source types either
> >>>>
> >>>> as part of
> >>>>
> >>>>>> the package or
> >>>>>>
> >>>>>>> for custom work by one user. We should
> >>>>
> >>>> probably also
> >>>>
> >>>>>> recognize a
> >>>>>>
> >>>>>>> directory under ~/.gramps for user-built
> >>>>
> >>>> source type
> >>>>
> >>>>>> glade files.
> >>>>>>
> >>>>>>> One challenge with this is that there will be
> >>>>
> >>>> some
> >>>>
> >>>>>> work to do on
> >>>>>>
> >>>>>>> upgrades, exports and imports, as well as
> >>>>
> >>>> work to do
> >>>>
> >>>>>> on reports etc.
> >>>>>>
> >>>>>>> One possible mitigation would be to return a
> >>>>
> >>>> string
> >>>>
> >>>>>> built from the
> >>>>>>
> >>>>>>> individual elements when reading the
> >>>>
> >>>> "volume/page"
> >>>>
> >>>>>> info for a source.
> >>>>>>
> >>>>>>> Such an approach might mean less downstream
> >>>>
> >>>> impacts.
> >>>>
> >>>>>>> For now, I just want to socialize this idea
> >>>>
> >>>> among the
> >>>>
> >>>>>> gramps'
> >>>>>>
> >>>>>>> developer community.  Please criticize, add
> >>>>
> >>>> to it
> >>>>
> >>>>>> or tear it down (if
> >>>>>>
> >>>>>>> it is completely loony!)
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Dec 17, 2009 at 8:18 AM, Doug Blank
> >>>>
> >>>> <dou...@gm...>
> >>>>
> >>>>>> wrote:
> >>>>>>>> On Thu, Dec 17, 2009 at 7:09 AM, Duncan
> >>>>
> >>>> Lithgow
> >>>>
> >>>>>>>> <dun...@gm...>
> >>>>>>
> >>>>>> wrote:
> >>>>>>>>> Like me a lot of amateur genealogists
> >>>>
> >>>> have the
> >>>>
> >>>>>> goal of writing a
> >>>>>>
> >>>>>>>>> family history as a book, perhaps
> >>>>
> >>>> illustrated,
> >>>>
> >>>>>> hopefully with source
> >>>>>>
> >>>>>>>>> notes.
> >>>>>>>>>
> >>>>>>>>> So, what can Gramps do to help with
> >>>>
> >>>> this? I
> >>>>
> >>>>>> have two ideas:
> >>>>>>>>> * Make a way of referencing sources
> >>>>
> >>>> directly
> >>>>
> >>>>>> from a note, so notes can
> >>>>>>
> >>>>>>>>> become part of a narrative with
> >>>>
> >>>> sources.
> >>>>
> >>>>>>>>> * Make the Gramps source list
> >>>>
> >>>> exportable in
> >>>>
> >>>>>> some standard form which
> >>>>>>
> >>>>>>>>> apps like OpenOffice can use.
> >>>>>>>>>
> >>>>>>>>> Personally I prefer the second idea,
> >>>>
> >>>> Gramps
> >>>>
> >>>>>> should not become a word
> >>>>>>
> >>>>>>>>> processor. What do others think?
> >>>>>>>>
> >>>>>>>> The second can be done as an addon
> >>>>
> >>>> Report. I have
> >>>>
> >>>>>> some Python code
> >>>>>>
> >>>>>>>> that can format BibTex and EndNote [1].
> >>>>
> >>>> If you
> >>>>
> >>>>>> write up some notes on
> >>>>>>
> >>>>>>>> how that would work, I can provide a
> >>>>
> >>>> basic addon.
> >>>>
> >>>>>>>> The first would involve some work, but
> >>>>
> >>>> might be
> >>>>
> >>>>>> related to something
> >>>>>>
> >>>>>>>> else I'm working on. I've been working on
> >>>>
> >>>> a
> >>>>
> >>>>>> mechanism for providing
> >>>>>>
> >>>>>>>> "links" in the GUI to take you to other
> >>>>
> >>>> parts of
> >>>>
> >>>>>> gramps. For example,
> >>>>>>
> >>>>>>>> in the TODO Gramplet, it would be nice to
> >>>>
> >>>> add a
> >>>>
> >>>>>> list of people with
> >>>>>>
> >>>>>>>> links, so that it would take you to that
> >>>>
> >>>> person.
> >>>>
> >>>>>> Perhaps this same
> >>>>>>
> >>>>>>>> idea could be "rendered" in other
> >>>>
> >>>> doctypes to
> >>>>
> >>>>>> include a
> >>>>>>
> >>>>>>>> bibliography...
> >>>>>>>>
> >>>>>>>> -Doug
> >>>>>>>>
> >>>>>>>> [1] - http://biblio.roboteducation.org/
> >>>>>>>>
> >>>>>>>>> Duncan
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>--------
> >>>>
> >>>>>>>>> This SF.Net email is sponsored by the
> >>>>
> >>>> Verizon
> >>>>
> >>>>>> Developer Community
> >>>>>>
> >>>>>>>>> Take advantage of Verizon's
> >>>>
> >>>> best-in-class app
> >>>>
> >>>>>> development support
> >>>>>>
> >>>>>>>>> A streamlined, 14 day to market
> >>>>
> >>>> process makes
> >>>>
> >>>>>> app distribution fast and easy
> >>>>>>
> >>>>>>>>> Join now and get one step closer to
> >>>>
> >>>> millions
> >>>>
> >>>>>> of Verizon customers
> >>>>>>
> >>>>>>>>> http://p.sf.net/sfu/verizon-dev2dev
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>>
> >>>>>>>>> Gramps-devel mailing list
> >>>>>>>>> Gra...@li...
> >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>--------
> >>>>
> >>>>>>>> This SF.Net email is sponsored by the
> >>>>
> >>>> Verizon
> >>>>
> >>>>>> Developer Community
> >>>>>>
> >>>>>>>> Take advantage of Verizon's best-in-class
> >>>>
> >>>> app
> >>>>
> >>>>>> development support
> >>>>>>
> >>>>>>>> A streamlined, 14 day to market process
> >>>>
> >>>> makes app
> >>>>
> >>>>>> distribution fast and easy
> >>>>>>
> >>>>>>>> Join now and get one step closer to
> >>>>
> >>>> millions of
> >>>>
> >>>>>> Verizon customers
> >>>>>>
> >>>>>>>> http://p.sf.net/sfu/verizon-dev2dev
> >>>>
> >>>> _______________________________________________
> >>>>
> >>>>>>>> Gramps-devel mailing list
> >>>>>>>> Gra...@li...
> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>--------
> >>>>
> >>>>>> This SF.Net email is sponsored by the Verizon
> >>>>
> >>>> Developer
> >>>>
> >>>>>> Community
> >>>>>> Take advantage of Verizon's best-in-class app
> >>>>
> >>>> development
> >>>>
> >>>>>> support
> >>>>>> A streamlined, 14 day to market process makes app
> >>>>>> distribution fast and easy
> >>>>>> Join now and get one step closer to millions of
> >>>>
> >>>> Verizon
> >>>>
> >>>>>> customers
> >>>>>> http://p.sf.net/sfu/verizon-dev2dev
> >>>>>> _______________________________________________
> >>>>>> Gramps-devel mailing list
> >>>>>> Gra...@li...
> >>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>>>
> >>>> --
> >>>> Gerald Britton
> >>
> >> ------------------------------------------------------------------------
> >>------ This SF.Net email is sponsored by the Verizon Developer Community
> >> Take advantage of Verizon's best-in-class app development support A
> >> streamlined, 14 day to market process makes app distribution fast and
> >> easy Join now and get one step closer to millions of Verizon customers
> >> http://p.sf.net/sfu/verizon-dev2dev
> >> _______________________________________________
> >> Gramps-devel mailing list
> >> Gra...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel

-- 
Peter Landgren
Talken Hagen	
671 94  BRUNSKOG
0570-530 21
070-345 0964
pet...@te...
Skype: pgl4820.2