Different data entry feedback behaviors on similar data types

Help
1

There are several different data validation feedback for different text entry fields:

  • The ‘Surname guessing’ text entry field
    • displays a predictive text drop-down menu list from existing surnames
    • menu items are NOT case sensitive matches
  • The ‘Date’ text entry field
    • changes field box and font color to red when cannot be validated
    • NOT case sensitive
  • The ‘custom type’ text entry field (with adjacent pop-up menu widget)
    • displays a predictive text drop-down menu list from existing built-in and custom types
    • menu items are NOT case sensitive matches
    • case sensitive error beep when comparing matches to the the string of an existing types
    • error beep for EVERY keystroke where the new string doesn’t match

Perhaps these behaviors could be harmonized for the Custom Type data entry field?

  • The custom type validate-as-you-type should NOT be case-sensitive. (To the point of auto-magically harmonizing capitalization with an existing custom/built-in type if attempting to ‘commit’ a string with mismatched case letters.)
  • The Custom Types could use the DateHandler’s Red error indicator in conjunction with a warning beep
  • subsequent warning beeps should be suppressed when the field is already has a red error indicator.

Discussion point that should be argued:

  • The error beep can be disruptive when Gramps is used in a library. It should have an option to suppress beeps in the “Warnings” tab of preferences.
  • On Surname entry, the desirability of an automatic Case Sensitive harmonization on ‘commit’ is arguable. It seems like it would generally be the desired behavior. But there might be situations where an odd capitalization instance would be desired.
2

The “Role guessing” test entry field
displays a predictive text drop-down menu list from existing roles
NOT case sensitive
error beep for EVERY keystroke except the first where the new string does match

I think it anomalous that there is surname guessing but no given name guessing: the latter would be more useful.

On surname entry, case sensitive harmonisation is not always needed: you should be able to distinguish between Mcdonald and McDonald.

David Lynch

3

The ‘Role guessing’ text entry field behaves no differently than any of the other Custom Types … doesn’t it? (Quite a few have contextually cued guessing: Event types, Name types, Role types. A list of Custom Type fields can be generated by using the Types Cleanup Tool. )

image
image765×693 40.1 KB

4

Surname guessing is very structured and only occurs from the Relationships view and is based on a Preferences selection in the Display tab. (The guessing is for the Father and Offspring only when using the couverture/patrilineal default of “father’s surname”. The compounding option of “combination of mother’s and father’s surname” does surname guessing for both parents and offspring.)

What kind of rules would be used for guessing of Given names?

Are you thinking of some sot of Namesaking system used for naming offspring? Or *Icelandic names where a person’s last name indicates the first name of their father (patronymic) or in some cases mother (matronymic) in the genitive, followed by -son (“son”) or -dóttir (“daughter”).
image