Default surname count and default surname origin type preferences

[dsblank]

Context

Today, every brand-new Person/Name created for editing (via "Add new
person" in any view, "Add child" in the family editor, the alternate-name
"+" button, etc.) always starts with exactly one blank Surname, and
that blank Surname always defaults to origin type None
(gramps/gen/lib/surname.py Surname.__init__: self.origintype = NameOriginType()). Users who habitually enter people with multiple
surnames (e.g. Spanish/Portuguese paternal+maternal convention) or who
always know the origin type up front (e.g. always "Patronymic") have to
redo the same manual steps — click "Multiple Surnames", add a row, set the
origin type — for every single new person.

This plan adds two new preferences, modeled directly on an existing,
proven pattern in the codebase: FamilyRelType already reads its default
value from config.get("preferences.family-relation-type") inside its own
__init__ when no explicit value is given
(gramps/gen/lib/familyreltype.py:63-66), and Family.unserialize()
always overwrites that config-driven default with real data
(gramps/gen/lib/family.py:244-245), proving the pattern is safe on
import/load paths. We mirror this exactly for NameOriginType.

• Feature A: checkbox preference "Start new people with multiple
  surnames" — when on, new blank Names start with 2 blank Surname rows
  instead of 1, so the person editor opens directly in its existing
  "Multiple Surnames" view (EditPerson._post_init,
  gramps/gui/editors/editperson.py:235, already switches UI purely based
  on len(surname_list) > 1).
• Feature B: combo-box preference "Default surname origin type" — sets
  what origin type a brand-new blank Surname gets, instead of always
  "None".

1. Config registration — gramps/gen/config.py

Add two new keys next to the existing name/surname-related preferences
(near preferences.patronimic-surname / preferences.family-relation-type,
around line 317-335):

register("preferences.start-with-multiple-surnames", False)
register("preferences.default-surname-origin-type", 1)  # NameOriginType.NONE

2. NameOriginType reads the config default — gramps/gen/lib/nameorigintype.py

Mirror FamilyRelType exactly:

from ..config import config
from ..const import GRAMPS_LOCALE as glocale
from .grampstype import GrampsType
...
class NameOriginType(GrampsType):
    ...
    def __init__(self, value: int | None = None) -> None:
        if value is None:
            value = config.get("preferences.default-surname-origin-type")
        GrampsType.__init__(self, value)

This is the only change needed for Feature B. Every bare Surname()
construction anywhere in the codebase (importers, preset_name, the
"+ add surname" button, etc.) already goes through NameOriginType() with
no explicit value, so they all automatically honor the new preference.
Surname.unserialize() (surname.py:140, self.origintype = NameOriginType(origin_type)) always passes a concrete value from
serialized data, so load/import paths are unaffected — same safety
argument as the existing FamilyRelType/Family.unserialize() precedent.

3. Shared helper for blank-surname count — gramps/gen/utils/db.py

Add next to preset_name (which already imports Surname/NameOriginType
from ..lib at line 39):

from ..config import config
from ..lib import EventType, EventRoleType, Name, NameOriginType, Surname

def new_surname_count() -> int:
    """
    Return how many blank surnames a brand-new name should start with,
    honoring the "start with multiple surnames" preference.
    """
    return 2 if config.get("preferences.start-with-multiple-surnames") else 1


def add_default_surnames(name: Name) -> None:
    """
    Add the default number of blank surnames to a brand-new name, and
    mark the first as primary.
    """
    for _unused in range(new_surname_count()):
        name.add_surname(Surname())
    name.set_primary_surname(0)

Also update the fallback in preset_name() (gen/utils/db.py:515,
currently surnames = [Surname()]) to surnames = [Surname() for _unused in range(new_surname_count())], so a "guessed" child/parent name that
ends up with zero inherited surnames (because the base person has none)
still honors the preference instead of silently collapsing to one.

4. Replace duplicated call sites

Replace every occurrence of the repeated

X.add_surname(Surname())
X.set_primary_surname(0)

with add_default_surnames(X) (import add_default_surnames from
gramps.gen.utils.db). Confirmed call sites (all construct a brand-new
blank Person/Name for editing — this is the full set, found via
grep -rn "add_surname(Surname())"):

• gramps/gui/editors/editperson.py:168 (EditPerson.empty_object()) —
  required for correctness, not just consistency: EditPrimary's
  change-detection (editors/editprimary.py, compares
  self.obj.serialize() against self.empty_object().serialize()) would
  otherwise falsely report unsaved changes whenever the preference is on,
  since the real new-person object (built elsewhere, see below) would have
  2 surnames while empty_object() still built 1.
• gramps/gui/viewmanager.py:1590 (add_new_person, global "Add new
  person" keybinding)
• gramps/gui/widgets/fanchart.py:2381 (add_person_cb) and :2396
  (add_child_to_fam_cb)
• gramps/plugins/lib/libpersonview.py:449 (add, People list view)
• gramps/plugins/view/persontreeview.py:121 (add)
• gramps/plugins/view/relview.py:1794 (add_child_to_fam)
• gramps/gui/editors/editfamily.py:363, 374, 384, 1355, 1367, 1385
  (north_american, no_name, latin_american child-name-guessing
  helpers, both the ChildEmbedList and EditFamily variants) — the
  placeholder is overwritten by preset_name() in most branches, but
  matters for the no-inherited-surname fallback and no_name()
  specifically.
• gramps/gui/editors/displaytabs/nameembedlist.py:166 (alternate-name
  tab "+" button — creates a brand-new blank Name for editing, matching
  Feature A's scope)

Leave unchanged (always add exactly one row regardless of the
preference, by design):

• gramps/gui/editors/displaytabs/surnametab.py:240 (add_button_clicked,
  the "+" button inside the multi-surname tab that adds one more row to
  an already-existing name) — it constructs Surname() directly, so it
  automatically picks up the Feature B origin-type default already; no
  change needed here.
• gramps/gen/lib/surnamebase.py:138 (get_primary_surname()'s defensive
  self-heal when queried on a Name with zero surnames) and
  gramps/gui/editors/editperson.py:~939 (save()'s safety-net fixup if
  the user manually deletes all surname rows before saving) — both are
  defensive fallbacks for an already-existing Name, not "new person"
  creation, so they intentionally keep creating exactly one Surname()
  (which still gets the correct default origin type automatically).

5. Preferences dialog UI — gramps/gui/configure.py

Add to the "Data" panel (add_data_panel, same section that already has
the preferences.patronimic-surname checkbox around line 1697-1707 and
the "Default family relationship" combo around line 1858-1872), right
after the family-relationship combo:

row += 1
# Default surname origin type:
no = NameOriginType()
origin_map = no.get_map().copy()
origin_map.pop(no.get_custom(), None)  # exclude "Custom", like SurnameTab does
if not origin_map.get(NameOriginType.NONE):
    origin_map[NameOriginType.NONE] = _("None")
origin_keys = sorted(origin_map, key=lambda k: glocale.sort_key(origin_map[k]))
obox = Gtk.ComboBoxText()
list(map(obox.append_text, [origin_map[k] for k in origin_keys]))
current = config.get("preferences.default-surname-origin-type")
obox.set_active(
    origin_keys.index(current) if current in origin_keys else origin_keys.index(NameOriginType.NONE)
)
obox.connect(
    "changed",
    lambda obj: config.set(
        "preferences.default-surname-origin-type", origin_keys[obj.get_active()]
    ),
)
lwidget = BasicLabel(_("%s: ") % _("Default surname origin type"))
grid.attach(lwidget, 1, row, 1, 1)
grid.attach(obox, 2, row, 2, 1)

row += 1
self.add_checkbox(
    grid,
    _("Start new people with multiple surnames"),
    row,
    "preferences.start-with-multiple-surnames",
    start=2,
    stop=3,
)

This reuses NameOriginType.get_map()/get_custom() (both already public
methods, the same ones SurnameTab.build_columns() uses in
gramps/gui/editors/displaytabs/surnametab.py:121-133 to build its own
origin-type combo) rather than reaching into the "private" _DATAMAP
attribute — so no new precedent or lint concern is introduced.
NameOriginType/Surname/config are already imported in
configure.py.

6. Layering / lint

• Both new imports (gen/lib → gen/config, gen/utils/db.py →
  gen/config) stay entirely inside gen, matching the already-proven
  FamilyRelType precedent — no violation of the "gen must not import
  gui" rule.
• New functions (new_surname_count, add_default_surnames) need full
  type hints and concise docstrings per CLAUDE.md.
• Run black on every changed file; run mypy (note *.gpr.py files are
  excluded, not relevant here).

7. Tests

New file gramps/gen/lib/test/nameorigintype_test.py (no existing test
file for NameOriginType or FamilyRelType to follow, so this
establishes the pattern) — uses the real config singleton from
gramps.gen.config, saving/restoring preferences.default-surname-origin-type
in setUp/tearDown:

• bare NameOriginType() returns the configured default
• explicit NameOriginType(NameOriginType.LOCATION) ignores config
• default-out-of-the-box value is NameOriginType.NONE

New file gramps/gen/utils/test/db_test.py (create the test/ dir if it
doesn't exist) covering new_surname_count()/add_default_surnames():

• preference off → 1 surname, marked primary
• preference on → 2 surnames, first marked primary
• preset_name() fallback (no inherited surnames) respects the preference
  too

Verification

• Run the two new test modules directly:
  python3 -m unittest gramps.gen.lib.test.nameorigintype_test
python3 -m unittest gramps.gen.utils.test.db_test
  (per project convention, do not run the full unittest discover suite
  locally — that's left to CI).
• Run mypy and black --check on all changed files.
• Manually launch python3 Gramps.py, toggle both new preferences in
  Edit → Preferences → Data tab, then:
  • Click "Add new person" (toolbar / keybinding) and confirm the editor
    opens directly in "Multiple Surnames" mode with 2 blank rows when the
    checkbox is on, and that the new origin-type combo default appears on
    those rows.
  • Confirm closing an untouched "Add new person" dialog does not
    prompt to save changes (validates the empty_object() fix).
  • Add a child via the Family editor and confirm the same defaults apply
    when there's no father/mother surname to inherit.

[jcsaaver]

In my opinion, it would be better to have the possibility to set the multiple surnames editor as default, but keeping the default number of surnames as 1.
I made a rudimentary implementation of this by changing line 235 in editperson.py from

if len(self.obj.get_primary_name().get_surname_list()) > 1:

to

if len(self.obj.get_primary_name().get_surname_list()) > 0:

With this modification, if I enter a new person, by default the multiple surnames editor appears, but with only one blank surname. If I need to add a second surname, I add one by clicking the "+" (Only one click, versus 2 before the modification).
If I add a new person as a child of a known couple, two surnames appear.

I think this behaviour is better.

[jcsaaver]

Maybe there could be an option to set as default editor the one with multiple surnames, and if selected, another option could appear to define the default number of surnames