Roadmap for v5.3

Now that the release of v5.2 is behind us, it is time to think about the roadmap for the next major release. I’ve already posted to the gramps-devel mailing list, but user feedback is also important to us.

Firstly, I’d like to say that the time it took us to release v5.2 was far too long. At the start Covid was a factor, and then the amount of work required became large which was rather daunting. We must make an effort to release Gramps more frequently, and I have indicated that I am willing to trial a much shorter time between releases.

Next, and of more interest to users, is what new features do we want to see in v5.3?

I made a couple of lists contaning things that have already been mentioned to me. There are some big long-standing topics such as:

  • Using JSON as the raw representation of objects.
  • Allowing multi-user access.
  • Improvements to the Gramps types.
  • Modelling of ships and heirlooms - Perhaps creating a new “Thing” primary object?
  • Place enhancements - will depend on other decisions made.

Some Gedcom related enhancements will probably be less controversial:

  • Add creation date to primary objects.
  • Add identifier structure to primary objects.
  • Allow web-accessible files in media paths.
  • Add dates to individual and family attributes.
  • Add time and phrase to date objects.
  • New Submitter primary object.
  • Add translations to notes.

There are also ideas that I have probably forgotten. For example, the idea of sub-events seems to come up quite often in discussions.

I would like to hear what users would like to see in the next release, but please bear in mind that not everything can be implemented and we have to get developers interested in coding the new features.

If a feature is really popular though, it may influence our decisions and may even attract a developer.



  • Using JSON as the raw representation of objects. YES
  • Allowing multi-user access. YES
  • Improvements to the Gramps types. YES
  • Modelling of ships and heirlooms - Perhaps creating a new “Thing” primary object? SO RARE NOT BOTHERED
  • Place enhancements - will depend on other decisions made. YES

Some Gedcom related enhancements will probably be less controversial:

  • Add creation date to primary objects.
  • Add identifier structure to primary objects.
  • Allow web-accessible files in media paths.
  • Add dates to individual and family attributes.
  • Add time and phrase to date objects.
  • New Submitter primary object.
  • Add translations to notes.

My own would be
Ability to Configure which columns are visible for each view individually
Example I never want age displayed alongside events



Wish list in prioritized order:

  1. Main-/Sub-Events
  2. Events on Places, including first point.
  3. Extend the Repository, Source and Citation functions in Gramps with support for using CSL and reading (as minimum, sync would be better) a Citation Store file like BibTex or CSL-JSON to be able to utilize an External Bibliography/Citation Manager.
  4. A hierarchal system for Sources/Citations and Repositories with possibility to use Places as Repositories and visa verse.
  5. Change the JSON export (and if possible, import) so that it is compatible with one (any) of the Open-Source Open-Data formats for linked data like JSON-LD or any Open-Source Advanced Network Graph format.
  6. Using a multi-model database like ArangoDB, OrientDB or similar as backend in addition to SQLITE, Postgresql…
1 Like

Allow me to play Devil’s Advocate, if you will. I have some experience with a multi-user system (MythTV, a free, open source personal video recording system). In that case, and I suspect for Gramps, the vast majority of normal users don’t make use of the multi-user aspects. But it is significantly more complicated to install, troubleshoot and maintain.

In MythTV, there is a distinction between installing the “backend” and “frontend”. To simplify, the backend has essentially no user interface and handles recording videos and serving them to frontends. Users set up recording rules via the frontend and select recordings to watch, etc. MythTV uses either a MariaDB or Mysql database for television channel listing information and other data. In point of fact, the database can be run on a separate machine meaning a ‘basic’ installation could comprise three separate systems: database, backend and frontend.

In practise, typical users start with a single machine running the three components. A handful add another frontend or two so they can watch recordings on other televisions.

The “cost” is that a potential user–who just wants to record and watch TV–has to first get their head around some of this core complexity. There are easy install methods for single, combined systems but you can’t avoid the jargon completely. It is a non-trivial barrier for newbies.

I would hate to see Gramps become more complex for all users in order to satisfy a smallish group that really want multi-user access. I think it would be better to fork the project if some developers are really intent on multi-user. If they can provide a simple migration process, that’s wonderful.

My $0.02 (and Canada doesn’t even use pennies anymore).


1 Like

I agree. I am not even considering a client-server approach.

Multi-user access would be limited to making it safe for concurrent access to the SQLite database.

You can probably do some of this already by writing a citation formatter (new in v5.2) and a custom importer.

Again, you can do this using the existing addon mechanism. I may even be interested in experimenting with one of these databases myself when I have time.

Such a request was anticipated when we introduced the resizable column widths in editor tabs feature. It would be possible to expand this functionality to also change the column sort order and visibility.

Concurrent Access is all I would wish not client/server
Equivalent to Microsoft Access Relational Database functionality.

A hierarchical system for Sources/Citations and Repositories with
possibility to use Places as Repositories and visa verse.
I know this has been discussed and there are arguments both ways but was
wondering whether it would be worth looking again not that I would give
it a very high priority


Thanks for reply on that

Can’t the creation date be extracted from the Handle?

A hierarchical system for Sources/Citations could be interpreted in couple of aways:

  • Layered citations
  • Source/citation organisation (e.g. catalogues, collections etc…)

The modelling of places and repositories is something that we have inherited from Gedcom. If an event happened at a repository then you would need a Place, and if sources are stored in a place then you would have to create a Repository. Does this actually cause a problem? How close to we want to stick to the Gedcom standard?

Hierarchical Sources

Can I explain my logic here as to why it is an interest to me

Years ago I was using the Registration Districts/sub Districts of the BMD system for location of Births, Marriages and Deaths

Originally they followed Ancient County boundaries which are physical Places of long standing.

So I then Created in each County a dummy Place called “Registration Districts of” and under each to the Registration Districts was a dummy called “Sub District of”. These were then classed as Administrative concepts because this type of place is loosely related to a Physical Place but constantly changing with the whim of local/national governance and therefore not given a physical location.

I do a similar thing with Probate Registries.
So my places already have Sources and Citations associated with them via the Notes I create for individual events such as births.


A trivial one that bugs me

In lists of Events where a Date is included why can we not have the
leading zeroes included ie my preference is for 01 May 1920 not 1 May
1920. This would then mean all columns of dates would line up and look
as if it were meant to be.
01 May 1920
10 May 1920
1 May 1920
10 May 1920


1 Like

But to align properly with leading zeroes (or leading spaces) then the font would have to be a monospace rather than a proportional one as well.

 9 Jul 1920
01 May 1920
11 Apr 1920

 9 Jul 1920
01 May 1920
11 Apr 1920

And, to my eye, monospace fonts cheapen the appearance of the rest of the text.

I can’t really see that most of these ideas would have any impact on my
usage, although I might find a use for some of them if they are implemented.
However, I do see a need for either better documentation of the place
structure or enhancements to it. The biggest problem I’ve encountered
is when I’ve attempted to specify a date range in the Place Name Editor
dialog, maybe because I haven’t used it consistently enough. As an
example, I tried specifying the date range “after 11 Nov 1889” for the
state Washington and “from 2 Mar 1853 to 11 Nov 1889” for the territory
Washington, but I did not specify a date range for places enclosed by
one or the other (although I sometimes listed both places on the
Enclosed By tab with different date ranges for places associated with
events that happened before Washington became a state). A consequence
was that for events with no date (which I frequently do for burials as
well as events that I don’t have a date for), the place will be
displayed with a “?” in the name where the state would normally be.
Also, in the Place index in the Narrated website, “?” appears in the
name for some of the same places.
I would like to do a better job of tracking changes to places through
time than I have, but problems like this make me wonder if it is worth
the effort.
Related to places, I think a few improvements could be made to the place
pages in the Narrated website. I would like to see the place type added
to the pages and I would like to see links included more consistently
for places that appear on the page. For example, Enclosed By and Place
Encloses are sometimes shown with links, but not always, and none of the
places in the first part of the page (City, County, State/Province,
Country) have links. I suspect but am not sure that the problem is that
places of custom types are handled differently.


I support improvements to types, places, grouping of sources/citations.

When it comes to grouping of sources, for what I currently have used until now, It wouldn’t matter if its actual layered sources/citations, or if its only organisation. Any of them would be better than now.
It would let me have the plenty sources I have that is the same magazine/journal grouped together in the list :slight_smile:

When it comes to place enchantments:
Would it be possible to put multiple coordinates on a place with date ranges, or make places inherit coordinates if they have none/an option is selected?
Even having to put in some word in to the coordinate field to mark it so it inherits, would be fine.

I agree with having leading zeroes. No matter what the font is, I think it would look better than without the zero, in my opinion.

Not related to Gramps, but:
Maybe it would be useful for feature requests on Mantis to have an upvote button(“I want this too” button)? I try to summit there when I remember things when they arent there already.

1 Like
  1. Could there be a new category view oriented around research? Think of how the “Combined View” within the Relationships category. It is essentially a combination of things that were already visible in the existing Relationship View (with the use of gramplets for Details, Children, Events, etc.), yet the new view makes it possible to see more at once and open things with a single click rather than a double click. It’s also a more interesting layout rather than just lists. While the Combined View is centered around a person and their relationships, it makes me wonder if there could be a new category view centered around a research topic or goal, including relevant repositories, sources, citations, and notes.

  2. As a user who is comfortable making small changes to the code, I would like to see ways to make built-in things easier to customize. For example, adding a column to the Person category view involves changing a number of files, after first figuring out which ones need to be changed. There is, of course, the alternative of creating a completely new view as an addon, but in this example that would mean reimplementing 99% of the original view, and having to maintain all of that redundant code myself. Another idea along these lines would be to enable new types of addons, for example being able to add tabs in the lower half “notebook” section of the editor dialogs.

  3. Is some large-scale review of the outstanding feature requests needed (and perhaps dreaded)? If so, could it somehow be assisted by AI? By the way, of the approximately 1,400 open feature requests, only half are “confimred”, while most of the other half are “acknowledged”. What’s the difference, in practical terms?

1 Like

Yes. Good idea. We should probably start a new topic to discuss the details.

Yes, but we would need a volunteer.

“Acknowledged” probably means that someone has read and understands the request. “Confirmed” probably means that they think it is a good idea. I’m not sure.

Perhaps we could use this forum somehow? One topic per feature request in a new category.