What's in development for Gramps 6.2

We are very close to the Gramps 6.1 release. You can see the technical contributions already accepted (“Closed”) and considered (“Open”) here: GitHub · Where software is built

What’s next? Here are the features and improvements being considered for Gramps 6.2 that is planned to be released in Oct 2026. Is there something big that hasn’t been started yet that you are hopeful for? Let us know.

New Calendar Support

  • #2369 — Chinese Lunar Calendar (农历)
  • #2374 — Vietnamese Lunar Calendar (Âm Lịch)
  • #2375 — Korean Lunar Calendar (음력)
  • #2376 — Japanese Imperial Era (和暦)

User Experience / Onboarding

  • #2394 — First-run onboarding tour with step-by-step popovers
  • #2388 — Prompt new users to import the Example Family Tree on startup
  • #2377 — Add an info button to the date editor with calendar/syntax help
  • #2214 — Simplified Interface (reduce complexity)

Data Entry & Editing

  • #2338 — Add Separation event type and related family types
  • #2372 — Add Event and Citation table support to CSV importer
  • #2351 — Display images according to Exif orientation tag
  • #2269 — Quick Add bar in Select Place dialog for comma-separated hierarchy entry
  • #2267 — “New” button in Place, Source, and Citation selector dialogs
  • #2296 — Show date format examples in Preferences Data tab
  • #2165 — Save filter dates in locale-independent format
  • #2141 — Coalesce event role types (schema change + upgrade)

Views & Display

  • #2217 — Spousal labels in the Relationships view based on family type
  • #2215 — Support for multiple named dashboards
  • #2223 — Place Cloud gramplet
  • #2164 — Better default Tag colors

Clipboard & Sessions

  • #2273 — Persist clipboard across sessions; filter view by active database
  • #2299 — Allow gui.clipboard to import without a default screen

Filters

  • #2305 — Drag-to-reorder UI for rules in the filter editor
  • #1963 — Allow filters to be cancelled

Performance

  • #2324 — Push include_classes filter into SQL (schema change)
  • #2229 — Reduce number of DB queries on open/close
  • #2178 — Add JSON field indexes on json_data handles (schema change)
  • #2177 — API for overriding filter rules on DB backends
  • #2160 — Optimizer: skip loop when all rules are optimized
  • #2111 — Graph algorithms improvements
  • #2109 — Database config

Plugin System

  • #2252sniff_function support to ImportPlugin for version-aware dispatch
  • #2250 — Allow requires_mod entries to specify pip package name and version
  • #2220 — Add SIDEPANEL plugin type for pluggable right-side panels

Infrastructure & Build

  • #2192 — PyInstaller-based Windows All-in-One (AIO) build
  • #2289 — Specify the required GTK version
  • #1988 — Fix man page updates

Reports

  • #2208 — Major upgrade to Latexdoc report
  • #2050 — Fix icu/PyICU exception handling in Narrated Web report
  • #2142 — Subdirectories and comments in Narweb CSS files

Code Quality / Type Hints

  • #2233 — Modernize type hints across the codebase
  • #2232 — Additional type hinting for DB-related classes
  • #2184 — Add type hints to gen/lib classes and fix filter rule type errors
  • #2128 — Protocols for typing of Gramps objects

Bug Fixes

  • #2237 — Fix resource leaks
  • #2195 — Refactor proxy system: two-layer include/sanitize filtering
  • #2149 — Add resilience to set_birth_death_index() for storage backend failures

Relationship Tools

  • #1882 — Refactor Relationship Calculator and add a search bar

48 open items as of 2026-06-20. Source: GitHub · Where software is built

A field for entering URL - mostly needed for source/citations. This has been asked for several times.

NB! I don’t want to start a discussion here, whether URL links are stable or not, thanks.

This has been proposed as part of the implementation of CSL which has variables for both the url and the date it was accessed. I think that @StoltHD was also interested in this.

If you are interested in what “CSL” is, read this: Citation Formatter - #10 by Nick-Hall

tl;dr

CSL - Citation Style Language

What I always find a bit annoying is entering the date.

Having to manually add the period after the day and month is a little irritating. I once had a program that automatically added the periods after the day and month. That speeds up the process a bit.

So I just type 01121720, and after pressing Enter, the system changes it to 01.12.1720. Maybe something like that is possible somehow.

That’s nothing big that I’m waiting for.:upside_down_face:

Ok, yes that is a small request and I was looking for big projects that need to get started before the Oct 2026 release date. But, since we’re here: You can already enter YYYYMMDD, but I think we could handle the three variations based on locale:

  1. YYYYMMDD - (e.g. Japanese, Korean, Hungarian, and ISO dates)
  2. MMDDYYYY - (US English)
  3. DDMMYYYY - (most of Europe, including German)

Here is a PR: Accept compact 8-digit dates without separators in date parser by dsblank · Pull Request #2406 · gramps-project/gramps · GitHub Tabbing to the next field should put the dots in for you.

  • Option to make double-clicking a media object open the image viewer by default instead of opening the editor.

  • In the People and Family Editors, clicking the citation icon opened the citation directly rather than opening the Event Editor first, where I then have to click to the Citations tab and click into citation again.

    • The same idea would be useful anywhere linked information is, such as Places and possibly Main Participants as well.

See this thread.

With the risk of this once again being drowned out in noise, derailments, and straw‑man arguments, I’m giving it another try. These topics has been discussed many times over the years, and I’ve raised it repeatedly since the Gramps 5.x era.

Here it comes:
There are three features I still hope to see in Gramps, and two of them I had hoped would arrive in the 6.x.x series. Those two are:

  • Main/Sub‑Events

  • A multi‑layer Citation/Source/Repository system, including full CLS support and the ability to read/write csl‑json and BibLaTeX files.
    With this in place, it would finally be possible to use external bibliography tools—not only Zotero‑like software, but also LaTeX/BibLaTeX workflows for those of who work with LaTeX.

The last feature in this phase is “Events on Places”, but Nick mentioned at some point that this still needs further discussion within the developer group…


And just to mention a few events that would directly benefit from the Main/Sub Event function:

  • Migration
  • Military units and military campains
  • Seamen on ships in merchantil trafic
  • Any type of building a new home, moving etc.
  • Census registration and more detailed Census research projects

And when this is added to places as “Event owners/Event holders”, it will be possible to do place studies, Farm and property history, more detailed military campain research, more detailed migration events, more correct sensus registration etc.

All of those mentioned and many more scenarios will also be registrered more historically correct.

The CLS was already mentioned, and @Nick-Hall and @StoltHD were interested in it. Either of you going to work on that?

The others (Main/Sub-Events and Events on Places) sound like they are still being discussed. I guess we are waiting on @Nick-Hall to help define/design/decide on those. (If there were a full spec that I could feed my AI environment, I could help. But I’m out of the loop on those two.)

Sorry, I misunderstood. I thought the question was directed at users about what we felt should be included. My mistake.

No, you’re good! In fact your response was exactly what we want: what’s missing and who is going to work on it. Thank you!

Here are some feature requests I’ve been following for a while (hoping they will be implemented someday):

4627: Use of custom filters from command line

10656: Allow sorting on multiple columns in various menus

4970: add Attributes as column to the list/tree views (mainly person)

11449: Add person filter related to <filter>

10672: Sub Events on Events and Recursive Hierarchy View of Events

Unfortunately, I feel that I must prioritise administrative tasks at the moment. I can summarise previous discussions and help with the design though.

Main/Sub‑Events

I agree with this in principle and can see how it would be useful in research.

This should be fairly easy to implement. I would start by adding a main_event_handle field to the Event object to create a hierarchy. Then the field could be added to the event editor and we would need to create an event tree view. Some reports would probably have to be modified.

Other designs could be considered.

A multi‑layer Citation/Source/Repository system

I also agree with this, but we don’t have a design yet.

The CITE plugins were an attempt to encourage experimentation, but they have limitations. They only used for bibliographies in reports and formatting is not supported. We would need the formatter to support the various output formats available for our reports.

We are making slow progress though. I think that we generally agree on using CSL variables. Although we should provide templates, we probably don’t want to attempt to adapt them directly from Evidence Explained.

This needs more discussion and further design work.

Events on Places

A good example of this is modelling a ship as a place. This is good for describing an event happening onboard a ship. However, if you then want to record the building, sale, overhaul etc… of the ship then it needs to be the subject of the event.

I think that this could be misleading and possibly be misused.

An alternative would be to create a new Property object which could model things like possessions and forms of transportation such as ships or cars. Maybe the Property object could be used as both a place and a subject of an event.

This also needs more discussion.

Feature request #10672 is the Main/Sub‑Events idea. This comes up quite frequently.

There was an earlier discussion about spinning some built-in plug-ins out to the Addon collection. (Such as reducing to a single built-in Navigator mode so the selector is not yet necessary.) Those choices are about making the interface more tidy.

But this is the flipside to that. Perhaps we could discuss rolling in some addon plug-ins into the core? Or nominate some for a ballot?

The ones I would add to a ballot for consideration would be:

  • The Theme preferences (maybe even an advanced Themes with CSS layer management) is an obvious candidate. Too many users want Dark mode.
  • The Date Calculator would be more useful if it was more available when needed. Like the new GUI calendar adds that GUI accessibility in the date editor dialog.
  • The Import Text would make an alternative data entry system available earlier in the onboarding process. Before they surmount the Addon installation point in the learning curve.
  • The Plugin Manager Enhanced seems to be the more commonly used version of the Plugin Manager
  • Replace the Edit → <object> Filter Editor with the Isotammi Filter Params tool. (If for no other reason than the ability to manage Filters from all categories within a single dialog.)

I have a list of small annoyances or possible improvements I’d like to see in a future release (6.2 or otherwise). I might give some of them a try this summer.

  • Add a search bar in the Geography view (that would be located on the top right or top left of the map) to search for a place by name in the local database (only places with coordinates) or on the web (the source would need to be configurable). There would be a dropdown with results, and clicking on a result would send you to the location.
  • Add a layer button on the Geography view (bottom right probably) to quickly switch to a different map provider
  • Custom role types on event reference are not saved like other types. It should be possible to select a custom role in the dropdown
  • In the Media Refererence editor, it is hard to zoom, move and select (even being experienced now, I sometimes use the mouse to try and move the image, which selects a part of the image instead). Maybe using click+drag to move the image and ctrl+click+drag to select a part of the image would make it easier?
  • Currently, when you click on the top or down buttons in the children list of the family editor, the child is unselected. In the event list of the person editor, the event is still selected, so you can move it multiple places easily. It would be great to be able to do the same with children of a family.
  • When creating an event and clicking the calendar icon, you have to change the date type to be able to select a calendar.

That would be great if you can work on some of these. (I just fixed the last one last week.)

You can. A single list of built-in and custom types is presented. Start typing and the list starts to filter.

If anything, the improvement needed is the list needs to be alphabetized. The same for all drop-down lists.

Live switches for the Gramps Environment?

I have been hoping for a while that Developers would find a way around the “* Requires Restart” requirement in Gramps Preferences :

  • Data
    • Date format
    • Age display precision
    • Display ages for events after death
  • General
    • Show text label beside Navigator buttons

And live switching of the Current Locale would be useful too. (Useful in different ways for: polyglot users, developers, support volunteers, WikiContributors and testing translations):