This is an off-the-wall question where I’m expecting that the answer will not be just “no.”, but that it will channel the Will Smith catchphrase of “Aw, hell no!”
I’ve put him in touch with Hans Boldt (who recently created such a Consanguinity Gramplet which includes a basic block diagram) and am trying to contact Heinz Brinker who created the RelatedRelatives Gramplet in 2011. (But the last posting found from him in the maillist is Nov. 2014. [Heinz replied the next day.])
Since Hans’ Consanguinity add-on is hung up in peer review, I tried to introduce the idea of downloading the Consanguinity gramplet and manually installing. From the Professor’s response, I think he mistook my description of the Gramps Plugin Registration file as a codebase agnostic tool for passing data & parameters to any tool that accepts CLI command & a compatible data pipe.
But the conversation made me wonder: is that a possibility? If someone write a standalone tool that will accept a GEDCOM with a set of parameters, is there a way Gramps could allow them to be dropped into a plugins folder and just write a fairly generic Options dialog in python to wrap it up as a new Gramps tool? (So Gramps would output a filtered GEDCOM to a temp file, then call the external tool to process that temp file with whatever option flags are supported in the Gramps tool option dialog.)
Here is my hope as a user: once the pickled blobs in the database are replaced with JSON strings, it should be easier for other applications to read the data. Ideally the database could also have some useful common view definitions, and the ability for users to add some of their own, so that applications don’t have to do all the work of joining the tables. Maybe there could also be an API to leverage such views as well as custom filters, but just exposing the pickled data would be a useful first step, eliminating the current need for export to SQLite.
We seem to be a fair distance from not being pickled. That was apparently a bit too far to fit on the 5.2 roadmap. And since upgrades are generally more than a year apart, I’d guess that 5.3 (6.0?) is at least 18 months away.
But even if other applications can directly read our SQLite db file, we’d still need to work out negotiating record locking. And probably probably add more fault tolerance if external packages are ever allowed to commit changes.
So it seems like some sort of handoff (GEDCOM, CSV, XML, JSON or KML) would be more viable. Dunno if that needs to be by mutually accessible file location, transfer/upload or by pipe? And whether there would be any data communicated in return is a whole other question.
The mongodb backend is not pickled and if you know how to connect and use mongodb, the data can actually be used in any software that can connect to it…
but for some reason after a new install on wsl2, I can no longer connect the Gramps on Linux to the database on windows… something about a wrong str. where it should be int…
But even with outdated python driver on Windows, it works, I find it stable but a little slow for some thing…
There has been a few posts regarding connecting to the Gramps db-api from external software/scripts, but I have never found a document explaining it step by step.
Nick answered someone a while back that needed to change something in an external script and I think he got it to work.
There is wrappers for Python for most other large languages now, so it might be possible, and R do have some Python “things” to be able to execute python inn R that can be added if I don’t remember wrong (way over my knowledge level).
A follow-up to the feedback discussion with Professor José Luís Moura Borges about his Consanguinuity visualization (included Gramps add-on contributors: Hans Boldt & Heinz Brinker)
The discussion was productive. José’s work is being published in an academic journal and the R source is available on his GitHub repository.
José Borges, VisAC: An interactive tool for Visual Analysis of Consanguinity in the ancestry of individuals, to appear in the Information Visualization quarterly journal.
You may also be interested in looking at a blog post in which I am describing my various visualization designs to support my genealogy research, among which is this work.