Family Historian User Group

I am not sure if this is the right forum to post this in and I am not even sure if anyone would be interested, but I would like to see what peoples responses are.

I love family historian - particularly its support for the gedcom standard and its queries. However, I like to present textual data just the way I like it - which has lead me to look for ways of customising the output for reports etc. (beyond the customisation that Family Historian itself offers). I did for a time use lifelines (which has its own scripting system) in conjunction with family historian to some success but found its quirks rather awkward.

I was therefore thinking of marrying an existing scripting system (for example JavaScript/ECMASciript) with gedcom capabilities and the query syntax of Family Historian (for the technically minded of you, the Family Historian style queries would be embedded in the language a bit like RegExpr is in JavaScript). A very simple program might look something like this...

  for( INDI in GEDCOM.INDI ) {
     print( %INDI.NAME:SURNAME%', ',', %INDI.NAME:GIVEN%', 'n' );
  }


Of course, being a scripting system, users could share scripts and customise them as much as they like. It need not just be used for writing reports, but whatever the user wishes to do with it. What do people think, would there be a use for this? I intend to release the program and source code free of charge under a suitable licence if there is sufficient interest.

I have already written a lot of the code (in ANSI-C) for my own purposes, but obviously will not go to the trouble of completing it and tidying it up beyond my own use standards if no one else is interested. Please let me know you thoughts - I wont be upset if no one is interested!


ID:4141

There is a wish list item for this
http://www.fhug.org.uk/wishlist/wldispl ... lwlref=161

Personally I wonder if an exposed API solution might be better so you could use DLL type calls (or what ever the current flavour might be) and use a language of your choice.

Alternately LUA is designed for embedding and might be a reasonable choice.

Hi Jane

Thanks for the reply, I had considered LUA as an option (as it is very easy to embed), however, I felt that general users would be more familiar with a JavaScript like sytax as it is more widely known. LUA is probably more stable than my own partially complete subset JavaScript compiler/interpreter but could probably be easily tailored to suit if any potential users felt strongly about it.

You are quite right, some form of exposed API probably would be the better solution (if not quite so general or cross platform), however the wish list item is well over three years old and it was not popular enough to be considered for the recent v4 release - I am guessing a possible version 5 would be sometime away and have its own priorites. Although, of course I could be wrong I know v4 increased the amount of functions available in queries so was definately moving in the right direction.

I think this sounds like a great idea. I would certainly find use for it.

The only reason I suggested Lua is because I use it for Lightroom.

Thanks Jane, how did you find learning LUA, was it fairly easy to pick up and use?

No too bad, I have not done anything too advanced with it, just triggering post export actions and customising other peoples scripts.