Sure, I’d like to see the test script.
But how would such scripts be applied? And then how would the subset of objects be used for a filter in a view, export, or report
- the database query API
- the Query gramplet addon?
Sure, I’d like to see the test script.
But how would such scripts be applied? And then how would the subset of objects be used for a filter in a view, export, or report
I selected all 129K+ individuals returned by the filter (Ctrl+A) and set the tag for all of them.
I enjoy following these discussions and gain some really useful insights
into the workings of GRAMPS
More so since I took the decision to stick v5.1.6 given there was
nothing I could see in 5.2 worth my time on the upgrade process at which
point I thought about what would entice me to think again.
So now I can relax and enjoy the discussions more as intellectual concepts.
phil
I think your questions will be answered when you see the tests. I’ll DM it to you just to keep the traffic down in this thread.
We no longer support BSDDB.
That was meant to be an example
Replace with another current or future supported backend.
Well, this is interesting: I ran the AncestorsOf() rule/filter on all 2157 people in the Example tree.
I did all kinds of low-level things (SQL, unpickle, JSON_EXTRACT(), ast.literal_eval), but the biggest difference was a high-level code change. After the ancestor-collection part of the code was completed, it takes another 2 minutes doing things it doesn’t need to do.
I think we can get great gains without having to change much except how filters are applied.
Yes, all of the tree walking rules build a list of people in the prepare method. The apply method then unnecessarily loops through the database matching the objects to the existing list.
The poor performance finding duplicate people is also a high-level issue which could be improved by retrieving people from the database in surname groups.
I’m sure that there are other places where a better choice of algorithm would help with performance.
Using multiple tools and changing something that requires those tools to update their data ?? See video on UX: Essai CardView + FamilyTreeView
Couldn’t agree more, but to some extent the interface is the inefficient part. Change or add a date for marriage, starting from person view, that’s 11 clicks with the mouse…Auch!
5 Clicks if you do the same thing through GraphView which I do not think
is too bad that is one of the reasons I use GraphView for all data entry.
phil
3 clicks on the Relationships view!
Switching views back and forth is not very practical. One “edit” view with tabs or whatever would be much better, IMHO. The ‘Data Entry’ gramplet makes it bearable to add parents & spouses though.
I use the Relationships view for almost all of my family work. It allows one click access to edit the active person’s parents, their family and siblings and one click to their marriages, spouses and children.
Adding a new Source is about the only time I switch views. I will add new place records while in Relationships but will go to Places to fill out and set each new place’s fields as one of my last tasks of the day.
This is one of the intriguing potentials of the forms development project by @RenTheRoot
If that project ends up allowing easier design of data entry forms… and if the forms create objects (not just attributes and form data as secondary data), then this ‘endless pop-up dialogs during data entry’ aggravation will have a viable alternative.
I currently have a spreadsheet form that is 100% table copy’n’paste compatible with the Text Import gramplet.
Doing this within a Gramps form would eliminate training users to use and reset the form, worry about which delimiter (comma versus tab) is selected, and reduce the mousing to a single click.
Relationship View is good just personally more comfortable with GraphView and I think that is the strength of GRAMPS very nearly “all things to all people” and there will always be a price to pay for that at a personal level.
phil