That addresses the sorting problem. (Which is addressed for dates by using a hidden date “value” for sorting and a formatted date “string” for display.)
But what is does not address is the “Glade” layouts.
There’s another value-add for increasing the size from 4-place leading zero number (prepended with a category identifying letter) to 5-place: optimizing the layouts for forms and Charts.
If the default width is increased, some UI adjustments will slowly be evolved too. We can assume that some (if not “most”) needed layout tweaks will be overlooked when the defaults are increased. The tweaks to the Glade layouts (or whatever is adopted for GTK in the future) will lag behind.
If the format becomes dynamic, the impact on layouts will be too complex for UI designers to refine on. Gramps Layouts will remain relegated into a “programmer’s domain”… and that hasn’t exactly lead to Gramps being extolled for its GUI aesthetics
I don’t understand. Is this a different issue than what you raised re: changing the default ID formats?
“Dynamic” is probably not the right word for the proposal above. It really is making it easy to know when, and how, to run the tool. That is all. Then the issue of default size is largely removed (at least for gramps desktop).
But they are imported/exported as IDs? Do they need to be unique in GEDCOM (for receiving systems that depend on them rather than generating their own handles or other internal IDs)?
This is very much a more expensive check than just seeing if a ID is expanding the bounds of the formatting. I think we should keep that as a separate process.
I was trying to address @GeorgeWilmes concern that ID’s are a GEDCOM import/export item and the need to be unique.
Personally, I see the ID along the same way I see/use Tags. Meaningless outside the user’s working of the database. They never get printed and exist solely for my use. I hope to never have to see the ID unless editing its record.
There are several outstanding tickets related to leading zeroes I know that the default ID Formats defaults have been mentioned (and dismissed as being the wrong time or too insignificant to be addressed) several times.
The proposal does not have any impact that wasn’t there before. The only problem that it solves is notification of exceeding the range, and helpfully opening the reorder tool if requested.
Where to spend your time is your choice, of course.
It just seems like changing the defaults would be a 30-second patch for a developer and a bit of WikiContributor time. And it would close a few outstanding issues. (I’ll grant that such a superficial ‘fix’ might just be delaying a real solution.)
While coding in more automatic ID generation complexity and intelligence also adds more lead time, the need for new code review, additional automated tests.
From a users perspective. I use the ID as a label to differentiate between elements with the same name. If I have to delete one, I know I have the one I want. When I saw the IDs getting close to 9999, since it was user defined, I just updated the number to 6. That gave me lots of room for growth. Yes it would be nice to have the default changed so I don’t have to remember to fix it with a new release. Make it 6 and it likely will never need to be changed.
Handles are a bit more than just a random string. Nor so ineffective as you are assuming. The handle is a string that is encoded with some metadata meaning.
The handle can be decoded. There’s a discussion in another thread:
Extracting the creation date with certainty was only possible through 2025-09-30, when the date accounted for exactly 11 bytes of the handle, and the rest of the length was variable based on the random number. Dates since then account for 12 bytes, but since the random portion is variable, you can’t tell whether a handle contains an 11-byte or 12-byte date. (I guess if the change date is less than or equal to 2025-09-30 then you can assume the creation date is too.)
Maybe because I did not learn C before python, I often try to use a lazy direct (or mixup) way on code… So, for an experimental import script, I removed all Gramps IDs stuff and used a pseudo UID as handle for gramps object… Why ? Because there is an inherited check process (legacy) which complains for a conversion or something like that (old model for Gramps 1.0) during import. This has been removed on the script during cleanup, which was a little bit difficult to explain to AI during review…
So, even not a proper handle based on date but rather a pseudo UID for this script, the generated records into this custom Gramps XML will be imported into a new Family Tree.
True, maybe I should really use a right way for generating handle value, and except maybe a possible missing date value on the metadata record, what could be the risk to generate random handle record values before an import? About ID records, as we can import many dataset without ID, I did not really look at ID Formats, prefering a large range on handles values like maybe proper ID formats should do. Sure, an horrible and lazy mixup of design.
Note, does someone know how to easily corrupt a Gedcom file format?
Just set an ID twice…
I’m a bit confused now. For some reasons that are irrelevant for this question, I’m regularly using IDs with 34 characters without any problem. I understand this posting saying that only the first 6 characters are indexed and the remaining characters are ignored. Is this understanding correct? Thx for clarifying this issue.