GraphView Plug-In Enhancements

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

GraphView Plug-In Enhancements

tcorbet

As I am not a python person I am a bit ambivalent about starting this thread because I may not be able to finish it, but here goes.

01.  I find GraphView to be a rather remarkable addition to the very good facilities built into the concepts, architecture and implementation of Gramps.  As currently implemented, to the best of my knowledge [maybe someone will point out some configuration capability that I have missed], however, it has a couple of characteristics which do not suit my needs.  I have, therefore, spent a good deal of time this past week reading the code and the documentation from the Graphviz suite upon which it depends.  From what I have been able to apprehend, I believe I could modify GraphView to meet my needs.

02.  With that as a starting point, the reason for this posting is that I suspect that my needs may be similar to needs of many other Gramps users, so I would like to seek some feedback to see whether or not I could try to author something that would me worthwhile for others.

There are a couple of aspects to "my needs," come of which are likely not to be of general interest, so let me begin where I believe the greatest amount of interest might be.  The quick way to do that is to refer to this stackoverflow thread:

http://stackoverflow.com/questions/2271704/family-tree-layout-with-dot-graphviz

Now I realize that the thread is pretty long and that it was not directly concerned with Gramps, but you will, I believe, find it very relevant to the GraphView implementation.  So, the short description of this need would be:  "The rendering of the segment of a family tree selected via GraphView ought to have the classic appearance of a family tree with regular, orthogonal connecting lines."

03.  Beyond that there are, of course, some other details concerning the content, formatting or ordering of the person nodes in the tree, and some of those might also be addressed, but I don't think this is the time to worry about those details.  For a summary statement of why competent folk [with competency both in the subject matter of genealogy and algorithms for processing directed, acyclic graphs] who have worked hard on those objectives, and usually had to accept practical limits concerning what is achievable, I think you could google for a fortnight and not find a more generally agreed-upon statement than that which is found in the thread as being posted by the user called "EL."

The problem is, at least for me, that one does wish to nicely, compactly include more of the relationships of some selected person.  GraphView's logic does handle a somewhat more complex set of relationships exceptionally well, and manages to use graphviz.dot semantics to do a very good job of getting a rendering with no intersecting edges.

04. So with that background/context, these are my questions:

      A.  If you are looking for some similar enhanced capabilities, for your own purposes do you need  the output to be an interactive panel inside a Gramps session [basically maintaining the current functionality], or would your own needs be served by delivering a graphview.dot file that you would use in the rest of your workflow.

     B.  If your needs would best be met by the delivery of a graphview.dot file, are you OK, with the present implementation which uses Gramps' internal handles as unique identifiers, or would you prefer that the gramps_id be used.  [I realize that the second question gets to a pretty discrete level of technical detail, but I assume that if your interests/needs fall into the category of a graphview.dot file, you have acquainted yourself with the Gramps data model.  Indeed, you very likely understand that data model better than I do.  In my own use case, I create a slightly modified sqllite database built from an export of the Gramps database, and in my experience the gramps_id field must always constitute a valid 'natural key' for the table in which it appears, thus guaranteeing select queries with joins will yield the same result set as is obtained by performing the corresponding joins using the 'synthetic keys' called handles.]

05.  In summary conclusion, I am pretty well committed to doing some python  work to get what will be a more useful result for myself.  If you find enough overlapping interest, or if you ever would like to take on the python coding, I would like to hear your thoughts.

Thank you.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org