You really just want to change the sort order in the person tree view.
Try adding the following code to the end of the gramps/gui/views/treemodels/peoplemodel.py file:
def sort_name(self, data):
handle = data
cached, name = self.get_cached_value(handle, "SORT_NAME")
if not cached:
name = name_displayer.name_formats(data[COLUMN_NAME])
self.set_cached_value(handle, "SORT_NAME", name)
the added lines override the sort_name method that PeopleTreeModel inherited from the PeopleBaseModel, and that they reference name_formats instead of raw_sorted_name?
So my only question is why “” and whether having those values hard-coded may cause me any troubles later on.
Yes. It overrides the sort order for the person tree view.
 refers to one of the pre-defined name formats (First name, Last name).
 refers to the type of data passed to the function - raw in this case.
These values are unlikely to change.
It would have been better to use constants, but this is just a quick workaround before we come up with a more permanent solution.
From the same feature request, I offered up having the Default Display be different than the Default Sort.
My default display is Title Given "Nickname" Surname, Suffix.
I am also a heavy user of the Surname Override. So for most cases, this works great where in the Grouped name list John Clark shows next to John Clarke. But I do have to override the sort when there are Titles so that Colonel John Clark displays with his kinsmen.
The first time I started with how I currently display and sort names with these exceptions, I used an uncompressed xml export and did a global search and replace based upon the Name’s Type. These exceptions are stored with the type in the xml. But this is not a solution I would recommend to the casual user. Editing the xml file is fraught with danger of corrupting the file.
And this only works if these exceptions have their own name Type that need to set. I use two, Title and Rank.
But it looks like it could use some fleshing out. I was recently reminded that voting has no effect in feature development.
If, on the other hand, we can pique the interest of a developer (by exploring the concept fully with intriguing examples of how the feature would be broadly worthwhile) that might get someone to invest the time.
If we do enough of the homework, then someone familiar with the Gramps API can implement it with fewer hours of investment.
The way I understand @GeorgeWilmes 's request (11788) is at the time a Display Name is created, a Sort order can be created for that display option. A tandem setting…
Display Given Surname, Suffix can have the preset sort Surname, Given Suffix. The problem with Given Surname, Suffix as a sort in the Grouped Name list, John B Clark sorts before just plain John Clark. Not bad, but not ideal. This allows a natural Display option and a proper sort.
But if I understand correctly, instead of Surname, Given Suffix as a sort add an option for GroupAsSurname, Given Suffix to account for the Surname override.
Yes, and as I explained in that comment in the issue, the grouped surname was just my particular use case, but the proposed solution is more generic. If others among you have some specific use cases that would benefit from the same general solution, please share them in the issue. Thanks.
When I use the override I set all applicable names so both “Clark” and “Clarke” are set to “Clark (Clarke)”. In the Grouped lists it is very noticeable. Not so noticeable in other areas. I have filed a Feature to have the global Group As display in the name list along when an override is done on a case by case basis. They use different methods to affect the change.
I wonder if there is a way to search for Names with Grouping, displaying and Sorting overrides? Then a way to clear/set selected overrides en masse?
@kku , can SuperTool address these preferred and alternative name attributes? Experiments so far all return AttributeError messages. So obviously I should not be using the labels as listed in the SuperTool Help or Data Model documentation.
Note that the Master branch and PRs do not include a Sort enhancement for the People Tree. And none of the Bugs point towards a PR despite having a proposed solution in the comments. So it probably isn’t on the 5.2 roadmap.
And this sorting improvement doesn’t address sub-sorting namesakes (and recurrent given names in a line) in either the Tree or Flat Person lists. (Differentiating between eponyms and a multitude of Namesakes is a common difficulty in Genealogy. Sub-sorting by birth/death year or generation is a typical ordering in indices.)