Here’s one thing that’s always given me trouble. When adding an event, Gramps tries to be smart and automatically sets the event type, either to BIRTH, DEATH, or BURIAL, depending on what events have already been added. Often, when intending to add an OCCUPATION, I forget to change the event type, and end with the occupation specified on one of those other default events. (I just went through my events and found dozens of incorrect events because of this.)
I would prefer the event type initially set to blank with a warning if not specified.
Alternatively, I’d like to be able to set a default event type in the settings (perhaps with the current “smart” behavior as an option).
You might try forking the Data Entry Gramplet & giving it a 3rd (& 4th) configurable Event row for its form layout. You could every convert the existing labeled Birth & Death rows to the typical Event Type text field (with pop-up) but have those with defaults.
It’s already quicker than the multi-dialog Person/Event/Date/Source sequence… particularly if you’re transcribing multiple people from the same source.
Hans is an experienced Python coder who has already developed some add-ons. (His Cosanguinuity Gramplet has idling in peer review since August and his Tangled Web is a set of tools for publishing Gramps data on a self-hosted WordPress site.)
Hans would have to hack the source code to expand it for extra lines and selecting the Event type instead of the type being hard-coded. Such hacking is not an option for the average user.
Hi Brian! I’m not really interested in the data entry extensions. I’m too set in my current workflow, and I’m not sure how much faster I can get with that extension. There are always some details that need special handling, such as witnesses, and I’ve become quite adept at dragging and dropping to/from the clipboard.
Regarding my issue, I was just venting. I knew I had the occasional problem with not changing the default event type for occupations. But I didn’t realize how prevalent the problem was until I did a search and saw how many events were affected. With a number of searches, I think I’ve found and fixed all the incorrect events, and I’ve promised myself to be more careful in the future.
I understand the rationale for the current design, and sometimes the default does match my intent. Perhaps I’ll just write a tool that makes a list of occupations and looks for them on BIRTH, DEATH, and BURIAL events, and then fixes them automatically. That can’t be more than a few dozen lines of code.
Yes, the “birth, death, burial” defaults work most of the time for me too. But it almost never is appropriate that it goes back to “Birth” if all three exist.
So even a longshot guess of the next Event type would be right more often.
However, most often when doing transcription from a particular source type, there is a prototypical Event type that will be used.
If transcribing from a church log, it might be Baptism Events. If from an Obit, it might be current Residence or Occupation.
And those Events might share a date but certainly share a Citation.
So, maybe a better solution would be to have a new drag’n’drop functionality for the Edit Event Object dialog? Where it would be possible to clone/rubber-stamp the data entered, creating a New Event into the Events tab of a closed Person/Family or the Events tab if an Editor is open for at Person/Family?
So, if a 2Jan1899 obit noted: 3 surviving sibs still living in the home town, 2 went to pan for gold in California, 2 sibs & the parents pre-deceased then the workflow in the Relationships view would be:
Toggle on the Rubber-stamp mode (which suppresses Navigating the Active Person focus on a click, as well as making a click the same as a drag’n’drop cloning on the target)
click on the Parent & 2 dead sibs
Change the type to Residence & add the hometown as the place
Click the 3 surviving sibs at home
Change the Type to Occupation, put in a description of “gold-panner”, change the Place to California
Click the other 2 surviving sibs
close/cancel the “cloning mode” Event Editor
In this workflow, 9 new fully dated & cited Events with different IDs are created from a single floating dialog. Since each cloned Event was New Event, the Role could default to “Primary” instead of “Unknown” too.
For me, I normally start with BIRTH and DEATH events when adding a new person. Once those are there, the default becomes BURIAL, which is rarely what I want from then on for that person.
Probably the most common event type for people in my database is OCCUPATION for the males, and RESIDENCE for females.
Perhaps for you, but not for me.
It’s relatively easy to change the event type. Why do you want to create a very complex algorythm ?
Relax.
We have time to create our genealogy tree.
On a somewhat related point, I’m now working through fixing another problem in my data: OCCUPATION events with a blank description field. Yesterday, I spent an hour fixing problem events, and I still have more than a hundred events to fix.
This means going back to the original source document and locating the occupation for the person. It’s a slow process, but at least I generally include scans of the source document in my citations. In some cases, there really is no occupation, and then the event needs to be changed to RESIDENCE.
In a case like this, it would be nice if Gramps could issue a warning if you do something silly like leave the description blank for an event that is meaningless without a description.
Be interesting if there was a sanity check functionality where you can define the Rules for Sanity. I think they are hard coded now.
About the only places I’m aware of Sanity Checks upon commit is warn on unknown Gender and the Child to Parent relationship. (There are validator for Date & GPS CSV entry, but they are ultimately indifferent to commiting an unvalidatable value.)
I’d like a Sanity check for ‘unknown’ roles on Events. Because they are NEVER usable. added to the 5.2 Verify tool
So I spent the whole morning fixing up errors in my database. I found just a couple of instances of another error: Entering something into the ID field. It’s always bugged me that that field is input capable.
In general, I’d really like to see Gramps do a better job of warning about obviously not valid situations.
I’ve made the same mistake a few times, although I’m not sure what would
be a good solution. When I am adding a new person I am often starting
with the three events birth, death, and burial, so the defaults are
convenient at that time. On the other hand it is very rare that I would
have multiple events of any of those three types (except for a few cases
where I have evidence that a body was moved from one burial site to
another), so it would be useful if there was no default when editing a
person that already has those three events.
The custom User ID feature is absolutely necessary to my collaboration within the family. The core of my Tree is the research of my maternal grandmother. And she used a descendant numbering systems that started with her parents. So, for all those 250 descendants plus spouses, on all the charts shared with my maternal side, it helps that including the Gramps ID prints her IDs.
For initial roughing in with those 3 event times, I much prefer the Data Entry gramplet. It lets me add everything (including a citation) without popping up a single dialog.
Even better, for entire families who were born in the same city, died in the same town (even if they migrated to another town as a family) and were buried in the Family plot; all that needs be changed is a Given Name, dates, and changing Gender as indicated. I don’t even pop a single extra dialog!
(Yes, it has an annoying tendency to change the Active Person without being told to do so. But other than that, it is a vital part of my data entry.)
Hmmm, using the ID field to store a value using some custom numbering system seems odd to me. First, numbering systems are typically based relative to some particular person in the database, and of course breaks down once you get to in-laws.
Second, different numbering systems are used depending on the type of report you want. That is, a pedigree report will use one type of numbering, a descendant report a completely different system.
It seems like what you want would be better achieved using attributes. The main purpose of an ID is to provide a unique key for the item in the database.
So far, I’ve found just 3 cases where I accidentally entered data into the ID field, so it’s not that big a deal for me. I just think it would be nice if we had the option to make the ID field read-only.
If non-standard numbering systems are prevalent, that may affect how developers write their plugins. For example, for my Tangled Web system, I assume the default X01234 style of ID’s. (At least, I assume that most of the characters are digits.) I now have to rethink how I do some things, or at least recognize non-standard ID’s and handle them differently. (Not a big deal in my case, but it’s just one more thing to be aware of.)
An attribute is actually a awkward place for the custom IDs.
My preference would be to set up a Source for each numbering and use the Vol/Page Number for that system’s IDs.
But, the only extra data bucket that Gramps will print on virtually any chart & report is the Gramps ID. So that’s the one I use.
As for it breaking down for people outside the numbering scheme… not an issue for me. Those people just get a Gramps generated ID. (I only have one line that is hypersensitive to using their system.
If I find myself with another line, I’ll just write some SuperTool scripts that will overwrite the Gramps ID with that numbering system based Citation Page number. Crude, but usable.
