Could that be put off for a while? Some of the Plugin and features were rolled into core prematurely and have stagnated ever since. And others are overdue… like Themes
But rumor has it that LIB addon plugins might allow core elements to be overridden between updates in major releases.
Maybe this would be an opportunity to add Basic functionalities in the Core and demonstrate how a LIB could be used to expand it?
As a long as you make it clear to the user what to expect, then it is fine to delete multiple events. It must be obvious what will happen before the user clicks the button. This is why we often list changes in a confirmation dialog for tools.
We can add functionality to the core, but I don’t think that it should be necessary. Keep it simple.
Great, I will proceed with my planning with this as the assumed location.
Alright- I have made a note to try and keep it within a single window.
Good to know that it is within Gramps design guidelines that something like this could be implemented, I am still thinking over whether or not this is something that implementation would actually help more users than it hurts. I think it may be something I put off until future versions once feedback on the newer version can give a clearer overview of what users will actually want going forward.
Thanks for brining this up.
I’m still going through the code for the various addons to familiarize myself with how addons are integrated into the Gramps interface, but it appears to me that, like you said, instead of extending the existing preferences interface it replaces/overwrites said interface ( addons-source/Themes/themes.py at master · gramps-project/addons-source · GitHub ) I think this might be an easy fix that can be made once I am further along by extending the existing class used for preferences instead of overwriting (see: How to extend Python class init - Stack Overflow ) But I will keep this potential issue on my radar.
Gotcha I have luckily done quite a bit in the way of configuration file saving for my own projects so I will make sure that it is easy to save and load overall configs for this addon.
I’m probably using the wrong terminology.
What are the piece that are distributed with a release that are NOT core? The place the built-in master/gramps/plugins hold is self-explanatory.
I’d call it “document oriented workflow with Gramps”. Currently Gramps of course supports documents (i e sources and citations) but at least in my opinion, it does not support a truely document oriented workflow. Such a workflow would start with a document, extract all the information from it, and build the Gramps elements (people, events) without ever having to change the GUI view. Such a document oriented workflow has the obvious advantage that an information added to Gramps with that workflow has automatically and always a source/citation linked to it avoiding the wide spread problem of genealogies without any information about sources.
I’ve created a “poor man’s version” of such a document oriented workflow by using the Gramps XML file (the .gramps file) and not Gramps itself (since I didn’t want to learn Python and the Gramps internals necessary to create a Gramplet/report). I start with a document, enter all the relevant information in a web application (created with R and Shiny), and at some time, I update the XML file with the new information (again with a R app) and import it into a new Gramps database. That’s of course a bit clumsy, but I assume it’s the best approach without having to be a “full Gramps developer”.
Have you looked at RenTheRoot’s previously shared work? (Before working with Gramps.) There was already work contributing to a standalone tool (genscriber) that generates GEDCOM and that works that way.
And while I’d love to see such a Transcription tool in Gramps. Is it not a different approach on the project proposed? Like all contributors to Gramps addons, the developer is normally wanting to work on a feature that does something that is currently difficult for them to achieve with other features of Gramps or with other external tools in their toolbox.
Role for individual in census are census (or family) roles not person roles. In Gramps, Census events are linked to persons, not families, so, in France at least, census roles like Family head, Spouse,… are not relevant to people participating to that event, but fully relevant to their Role attribute in the census (and in its event attribute in Gramps).
A Family is a Group of individuals that are together at some point in time who may or may not be genetically related.
The Role in a census is the specific one to one relationship to the Head of the Household nothing more or less.
The idea of a drop down list of roles is possibly ridiculous and certainly unnecessary
phil
Sorry, I don’t have a Facebook account (really!), so I cannot see where your link points to. If it’s the GenScriber software Google points to, then it appears that this goes very much in the direction I’d call “document oriented workflow”. I’ll have a look at it, thanks for the information!
When this has been discussed previously, we have used the term “source-based data entry”. Where the data is structured we can define forms for data entry. If the data is unstructured, such as a will, then a different approach is needed. I have experimented with adding markup to transcriptions in such cases.
In my original prototype for the census gramplet, I stored the relationship to head of household data in the event role. This problem was that the participants in the census events were not recognised is primary. There are many places in our code that we look for role types of PRIMARY or FAMILY.
Selecting the relationship to head of household from a drop-down list would be interesting. We could use this to construct or perhaps just validate relationships. Different languages and cultures would have to be taken into account when compiling a list of relationship options.
I can live with that instead of “document based workflow” 
Ok, just kidding …
Where the data is structured we can define forms for data entry. If the data is unstructured, such as a will, then a different approach is needed.
At the end of the day, even a will is “structured” in same way, but we are of course thinking along the same lines. My argumentation would be that every document a genealogist might be interested in, is in some way structured. It will be possible to deduce at least one event from the document (e g in a will the event that a will has been written down at some date and place, another event that a certain heir is alive at that very date and so on), at least one person with a role in that event from it, a place, a date. So the most generic approach would be to have a form that supports multiple events, persons, roles. I’ve done such a form based on the XML file as described above and I would very much like to see such a form in “native Gramps”. This would help very much to implement a personal source/document based workflow.
You can extract information from all types of documents. Before computers, a genealogist would have written out an index card for each piece of information. These index cards would then provide the information to be used as evidence in conclusions.
By “structured” I mean that you know in advance what index cards you are going to create. This would be where the document is something like a form which has been filled in.
In a more “unstructured” document, you know the sort of information it contains, but need more flexibility in creating the index cards. A generic approach could be to have a dialog that allows the user to create any number of index cards for any number of people.
As an experiment, I created an editor with a pane containing a tree of people and information on the left hand side and a transcription on the right. The user could create any information for any number of people just by highlighting text in the transcription and clicking an “Add” button. Clicking an item in the tree highlighted the corresponding text in the transcription.
Goldie May has a .csv export of its research log. Maybe that could be useful?
In my situation I decided to implement two different approaches (the term “form” I’m using here means not a native Gramps form but a browser GUI that will modify the XML file):
(1) The first one is the creation of a small number of specialized forms for the documents I use most often: loan contracts, baptims (as a proxy for birth), death, marriages. That’s comparable with the existing census form in the sense that I exactly know in advance which information I’ll encouter and have to extract.
(2) The second one is a “swiss knife” form that is generic in the sense that I can use it in all other cases. This form will create as many events of the type l want it to define with links to individuals with the individual’s role in Gramps as I will exctract from the document.
I guess you would call (1) the approach for structured documents and (2) the solution for unstructured ones. In particular working with (1) is much faster compared with working in “native Gramps” but in my opinion, the most important improvement of that source/document oriented workflow is that the resulting Gramps data have a much better quality. I will never forget to link the citation, I will never forget to link individuals with their roles, I will never forget to input date and place of the event, and so on.
PS: I guess that the support of such a source/document oriented workflow would be a quite unique value proposition for Gramps. May be I’m wrong but I haven’t seen any genealogy software that would really fully support such a workflow.
I see it every day, on FamilySearch, when I join sources with persons. And I see the same when I process some hints on Ancestry, or My Heritage. But there, not all hints come from real records, so I use those much less.
On FamilySearch every ‘source’ persom has a unique URL, just like a tree person, and joining those, creating a tree person on the fly, if needed, is much faster than working with Gramps. It’s also a lot better than working with so-called evidence based programs like Clooz and Evidentia, which force you to use GEDCOM files as a transport layer.
I bet that this is why people like Ancestry so much.
Interesting! I do not use FamilySearch or Ancestry, but in my personal experience most “genealogists” (please note the “” here!) simply do not care about citations and sources for their data. I know databases for the region I’m specialising in with 600k individuals and not a single citation. May be I’m a bit too optimistic, but my expectation would be that a source/document oriented workflow (as far as I know that’s often called “evidence based” in the U.S.) in Gramps would help to improve the situation without being forced to the limited GEDCOM standard.
When I work to add sources to persons in the big tree on FamilySearch, I see this:
And you can see this too, when you create a free account, and like to work on that tree. You can then also download persons and associated sources with the ‘getmyancestors’ app, written in Python, which creates a GEDCOM file, and works quite good, and fast.
The reason that I show this, is that it’s fully evidence based, and uses a very simple user interface, which shows some record persons on the left, who live in the Ark, and ‘normal’ persons on the right, in the Tree. They all have individual URL’s, which contain ‘ark’ for record persons, and ‘tree’ for the others. And in this screen, you can see, that I can not only attach evidence persons, copying new data on the fly, but that I can also detach those, which makes the process very good for ongoing research.
Here on FamilySearch, I work on a shared tree, but I can do the same thing on Ancestry and other sites, and on all, the source persons are real top level objects in their database. And for me as a software engineer, that is a much better model than what the Forms Addon does, by storing person data in citation and event attributes, I think, where they are very hard to find. I think that it is far better to store them as real persons, just like those sites do, where they are linked to other objects in the evidence domain, like events, and documents. And in an object model, it is very easy to add nested ‘events’ to a person to store all the facts found in the source, and shown on the left. It’s also very clear to the sites’ users.
If you want to see for yourself, you can also create a free account on Ancestry, which gives you free hints for persons found in trees on Geneanet, where I have my tree too.
Can you recognize yourself here?
Yes, that’s me. Quite easy to say since it’s highly probable (*) that there has been only one Ulrich Demlehner who has ever walked on the face of the earth and that’s me And the company I worked at 40 years ago, filed a few U.S. patents with me as inventor, so that is where your citations come from.
I see your point but my situation is a bit special. I’m not really a genealogist interested in my ancestors and in building an ancestor tree (actually I started out as one of those guys). I’m more interested in the farmer community of a region in south eastern Bavaria in the 17th century and how this community is interconnected by ways of marriages, godparents, guarantors for debt, and so on. As a consequence, GEDCOM and databases based on GEDCOM imports don’t help very much since GEDCOM does not support a significant part of the information I extract from the documents. That’s the main reason why I have lost any interest in those public databases. And to make the situation worse, with the exception of the database without any citations I mentioned above, no database or research results for the area im interested in and worth reusing have been published anywhere.
(*) I can proof that but that would be a different discussion thread
