singhals wrote: > Ian Goddard wrote: >> Dennis Lee Bieber wrote: >>> On Tue, 12 Feb 2013 21:50:44 -0500, singhals<singhals@erols.com> >>> declaimed the following in soc.genealogy.computing: >>> >>>> kraut / larry stark wrote: >>>>> Suggestions for a good freeware genealogy program that is not too >>>>> complicated. >>>> >>>> If you're looking for MAC and free, don't believe there is one. >>>> >>>> If you're looking for unix based one, there is one, I just >>>> don't remember what it is; someone else will. >>>> >>> >>> Gramps http://gramps-project.org/ >>> >>> Should be usable on anything that can run a reasonably up-to-date >>> version of the Python language -- which includes Mac/Linux/Windows >>> (heck, some subsets of Python run on cell phones) >>> >> >> I rather fell out with Gramps after I upgraded to 3.3.1. Until that >> point I hadn't realised that it didn't keep copies of media files in its >> own database where, in my view, they should be kept. > > (G) Mostly to hold up the other end of the argument -- > FTM kept media in its internal database and most folks hated not having > access to the images from outside FTM. Easy. You only /copy/ them to the database. Don't delete the original. > After the first few images were put in, most everyone discovered the > database was growing exponentially, If that were really the case something would be wrong. It should just grow linearly. > and rather than reducing the number > of images they reduced the quality. I suppose this comes back to me having been a database developer working with an industrial-grade database engine. You want to keep bulky data? You allocate lots of space for it. > PAF5 like Gramps has you put the images into a separate directory; mine > are under PAF/Data/[dbname_img] and I finally got clever enough to put > the path into the NOTES > as a hedge against the next head-crash. AFAICS what Gramps was originally doing was to simply note the path & filename of what you supplied. Only at export time did it take a copy. That would mean if you reorganised what you though was an outside-Gramps system it wouldn't have been able to find anything. BTW I installed the current version onto another Linux instance on a VM & tried running the import again. It still has the same default locations but will allow a merge. But I'd forgotten another of its little egregious features which is still there. Each database has a name, e.g. 1881Census. But by the time you've exported & reimported it's something like Family Tree 01 so you have to go through the lot renaming them. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

Ian Goddard wrote: > singhals wrote: >> Ian Goddard wrote: >>> Dennis Lee Bieber wrote: >>>> On Tue, 12 Feb 2013 21:50:44 -0500, singhals<singhals@erols.com> >>>> declaimed the following in soc.genealogy.computing: >>>> >>>>> kraut / larry stark wrote: >>>>>> Suggestions for a good freeware genealogy program that is not too >>>>>> complicated. >>>>> >>>>> If you're looking for MAC and free, don't believe there is one. >>>>> >>>>> If you're looking for unix based one, there is one, I just >>>>> don't remember what it is; someone else will. >>>>> >>>> >>>> Gramps http://gramps-project.org/ >>>> >>>> Should be usable on anything that can run a reasonably up-to-date >>>> version of the Python language -- which includes Mac/Linux/Windows >>>> (heck, some subsets of Python run on cell phones) >>>> >>> >>> I rather fell out with Gramps after I upgraded to 3.3.1. Until that >>> point I hadn't realised that it didn't keep copies of media files in its >>> own database where, in my view, they should be kept. >> >> (G) Mostly to hold up the other end of the argument -- >> FTM kept media in its internal database and most folks hated not having >> access to the images from outside FTM. > > Easy. You only /copy/ them to the database. Don't delete the original. > Newbies don't think of /that/. They scan thru FTM and save where-ever it puts it. One copy, part of FTM. >> After the first few images were put in, most everyone discovered the >> database was growing exponentially, > > If that were really the case something would be wrong. It should just > grow linearly. You could be right, it's math after all, but 1 image tripled the file size on my test. 1, 300 dpi scan of a 2x3 B&W photo. >> and rather than reducing the number >> of images they reduced the quality. > > I suppose this comes back to me having been a database developer working > with an industrial-grade database engine. You want to keep bulky data? > You allocate lots of space for it. (G) But, you see, users don't think like developers. Users see "Store images internally" and they think COOL! They don't think, "How many images can I get on a 7G HD?" >> PAF5 like Gramps has you put the images into a separate directory; mine >> are under PAF/Data/[dbname_img] and I finally got clever enough to put >> the path into the NOTES >> as a hedge against the next head-crash. > > AFAICS what Gramps was originally doing was to simply note the path& > filename of what you supplied. Only at export time did it take a copy. > That would mean if you reorganised what you though was an > outside-Gramps system it wouldn't have been able to find anything. > > BTW I installed the current version onto another Linux instance on a VM > & tried running the import again. It still has the same default > locations but will allow a merge. > > But I'd forgotten another of its little egregious features which is > still there. Each database has a name, e.g. 1881Census. But by the > time you've exported& reimported it's something like Family Tree 01 so > you have to go through the lot renaming them. Ooops? Can't you change the code for the default to echo the file-name? Cheryl