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. In order to upgrade one exports a copy of each database in Gramps export format (which does include embedded copies of the media) and then reimports them with the new version. The import didn't reuse the old media files and their locations. IIRC if run interactively it will prompt for a location but as I have a lot of databases I scripted the reimport and it simply used its default location. Although the Gramps database files are kept in a single Gramps directory (.gramps in the user's home directory on Unix-like systems) the default location is the user's home directory. If, like me, you have a large number of separate databases (it's too messy to use a single database for work-in-progress) dumping a load of unexpected directories in the home directory can easily be regarded as a hostile act. I tried reporting this as a bug but the devs' opinion seemed to be that the user could simply move them to some more convenient spot & update the database manually which is not a particularly helpful response when the problem arises from having a large number of databases. What's worse is that (a) the import procedure tries to create these directories even if there are no media files and (b) aborts if the directory already exists. One could merge databases by exporting one, or a subset of one, and importing the exported file into another. This import now tries to create the media directory. As this is an existing database the media directory existed so the import failed. Although one can remove the media directory if it's empty (but why object if it is?) this becomes more difficult if it's not and pointless if the imported database doesn't even contain any media files. This is a particular annoyance as I kept one database as a gazetteer of places and used this to standardise recording but this needs to be periodically remerged with each working database. Clearly nobody tried to work through these use cases. Possibly the later versions have taken a more rational approach. I could try them out or I could go back to an older, saner version. Either approach seems so much hassle I keep telling myself it would be easier to start from scratch & write my own application. Until I do that I've almost given up Gramps and keep using a mixture of LibreOffice spreadsheet for sorting out families and an Informix database for register transcriptions. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk