I hope the original does not “go away”. I find the Combined view mode more tiring to read. I does have more functionality. But there’s more to sort through too.
The original Relationships view mode has simply presented vital statistics.
Worst case, it could be adapted to a Family view mode with the central node being a 2-column Family instead of a Person, it could become the first Family-oriented object navigator. And the top Parents section could be a 2-column display of the primary parents for each spouse.
One thing that would make everyday use much simpler is proper integration with CSL and CSL‑JSON, so we could rely on external bibliography software as the primary source and citation manager — while keeping Sources and Citations in Gramps updated by reading CSL‑JSON or BibLaTeX files.
The idea is straightforward: You enter the citation key in Gramps (or search for it), and Gramps pulls the corresponding data from the exported bibliography file. All relevant fields would then be populated automatically as attributes or structured data, depending on how the editor ends up presenting them.
And no — I don’t mean “Zotero integration” specifically. Zotero is just an example of software that already uses CSL‑JSON and BibLaTeX. The point is that any bibliography tool supporting these open formats could be used interchangeably.
If Gramps could also write back to these formats — not just read them — it would create a clean, two‑way path for interchangeable source and citation management across different tools.
Of course, this should not replace the current workflow, only complement it as an optional addition.
I tried to focus on those processes which require too many mouse clicks/navigation, or where visual cues, when displayed, should alleviate the need to dig deeper for data.
Back and Forward buttons should have popupmenus to see the list of entries in the stack and directly select one from there, instead of hitting Back/Forward multiple times. Can potentially remove many clicks.
Hotkey to “collapse all Nodes”/“open all Nodes” in People view and similar tree-like views. Removes one click.
A user option under Preferences to auto-sort when a new entry is added to a list. Defaults should be chronological order for events and children, time of addition for attributes, etc. There should be a set of orderings available for the user to apply to each such object list. Could remove many clicks, especially because one does not have to re-run Tools > Family Tree Processing > Sort children in birth order/Sort events at all.
When one selects “People” view, one has to additionally click into the window to be able to activate search by Ctrl+F. This seems to be one unnecessary click.
Simplify the FamilyTree > Export… process. It now takes at least 6 clicks. Should remember previously set configuration and autoname the resulting file. Could remove up to 6 clicks.
Ability to easily replicate (clone) citations, events, children, etc. Wen e.g. going through a baptism book, one records hundreds of almost identical citations, yet such data must be manually entered every time. Usually only the ID and row numbers differ and the ID is automatically incremented. One idea was to introduce Template objects ( Template objects ).
Ability to Configure which columns are visible for each object list individually. Could remove many clicks as otherwise one has to open each entry to see the required data.
Show tags in Relationship view (or Combined, if that one will prevail) by e.g. coloring names.
When Gramps is closed, the Clipboard disappears and its contents are lost, one has to manually open it again and add objects. Lots of clicks.
When a new event is added, the Event editor often misses the suggested type (I’d say most of the time, but this is surely user-dependent). There should be a row of “commonly used types” (Birth, Baptism, Death, etc.) close to the popupmenu, to be able to quickly select without the need to open the popup and select from it. Removes one click.
What upsets me most is the unusual window management in Gramps.
Windows are z-ordered according to internal rules set by ManagedWindow and GrampsWindowManager class. This z-order can be seen in the Windows menu.
Within a “group” of windows, you can’t change the “depth”. In other words, when you click in a window to activate it, it never comes in the foreground if it was not the topmost. You must move other windows (or minimise them) to have full access to the one you’re interested in.
“Groups” can be moved to the foreground but ordering inside the group is never altered.
One annoying consequence is the main window always remains in the background. Either you close all others or you resize them to work comfortably with the main window. Or you attach a second screen to you computer and spread the windows among the screens.
Every non-modal editor window (e.g., Edit Person) gets set_transient_for(main_window), so the WM permanently pins it above the main window. The main window can never come forward.
The fix: Only call set_transient_for for truly modal windows. Non-modal windows don’t need the WM to enforce their z-order.
def show(self):
if self.modal:
if self.other_modal_window:
self.window.set_transient_for(self.other_modal_window)
else:
self.window.set_transient_for(self.parent_window)
self.opened = True
self.window.show_all()
The trade-off: without set_transient_for, some WMs won’t group the windows in the taskbar together, and minimizing the main window won’t automatically minimize child editors. That’s a minor loss maybe compared to the current frustration of being unable to reach the main window at all.
I think this sounds like a new feature that needs a full specification, rather than being an annoyance that we must suffer. Can you write up a full description?
(@Nick-Hall this sounds less than a full GEP. A github discussion might be appropriate for this?)
Talking about window management, one annoyances is that the same window (e.g. the person editor or the event editor) move upwards every time you (re)open the window. Eventually all windows end up at the upper screen limit.
I’ve been measuring this movement, and it seems that every time you reopen a window it is moved upwards with exactly this thickness of the windows title bar.
Fixing this would be very much appreciated.
I agree. I’ll enable GitHub Discussions, and if developers like it maybe we can use it as our primary communications method development discussions. I’ll also post to the gramps-devel list asking for opinions.
I run gramps on Windows. In the person view ->internet tab, the drop down menu order can differ each time you start gramps. Doesn’t make sense to me because the sort order should be the same every time.
Regarding a write-up, I can explain how I think this should work once there has been a decision to actually implement support for reading, and perhaps also writing, CSL-JSON, BibLaTeX, and maybe BibTeX, as well as broader use of CSL.
I have already tried several times to describe how I use the tools I use, why CSL is a good interchange format, and why I think this could be beneficial for Gramps, while still working in parallel with the existing features. At this point, to be honest, I am getting a bit tired of repeating myself.
I see this also on Linux (Fedora 43). I suspect it has something to do
with how GTK populates drop-down lists. The place where I see it most
is in the Attributes dialog.
Example - I edit a person. Click the Attributes tab, then start typing
the name of an attribute in the first field. I have several attributes
that begin with “Fa”. When I type Fa in the attribute name, the
resulting subset gets a new sort order every time I run Gramps. It is
consistent during one run, but when I quit and restart Gramps it gets a
new sort order.
I use the keyboard for almost everything since it is much faster than
using the mouse. This change of sort order means the muscle-memory
keystroke sequence has to be learned again every time I run Gramps.
As noted below, it also happens in the Internet dialog box - both when
editing a person and when editing a place. I see when when choosing
between Wikipedia and WikiTree. Typing “Wi” results in a random sort
order. It is less annoying there since I do not use Wiki* URLS as often.
We already made a start in this direction by creating Cite plugins to act as citation formatters. I wrote a small prototype using the citeproc-py module to format citations in report bibliographies.
CSL variables were stored in attributes as well as in the standard GEDCOM fields.
I encountered two main problems:
Finding a suitable style definition. There appeared to be little or no support for layered citations for example. I couldn’t find any existing style that worked even reasonably well.
We need to format citations in an output independent manner so that different report formats are supported. The Cite plugins currently only output plain text.
I know you’ve been working on this for a long time, and although I haven’t had the chance to test your specific implementation yet, I have some thoughts on the underlying architecture regarding CSL and layers.
Regarding layered sources, I think the core issue is that there is no ‘correct’ definition of what a layer is. It depends on the source: is a layer a book and the next a page, or is it Archive > Shelf > Box > Document > Paragraph? For example, one user might want the ‘Book’ to be a layer just like the ‘Page’, while the ‘Paragraph’ is the actual Citation level.
Because of this, we should view standard CSL styles (like APA or Chicago) much like we view GEDCOM: as a standard subset of what Gramps can support. We shouldn’t limit Gramps’ internal engine to the constraints of these external standards.
My suggestion for the architecture:
The Mapping: When Gramps reads a CSL file or the user selects a standard style, the CSL fields/keys should have a setting where the user defines which layer in the Gramps hierarchy that specific field belongs to. Crucially, the UI must distinguish between hierarchical ‘layers’ and attributes for Repositories, Sources, and Citations. This mapping should be available as predefined templates that can be loaded, saved, and shared.
Dynamic UI: Source types and their corresponding fields should be read from the CSL file to dynamically populate the UI. This ensures the interface remains relevant to the specific source type being used.
Gramps-specific CSL: We could create a ‘Gramps Genealogy’ CSL style that supports our full internal hierarchy. This would allow users to create their own styles—much like we do with Forms. If the Gramps project agrees on a style that fits most users, we could even submit it to the official CSL repository, including language files. There is a huge lack of genealogical styles in the CSL catalog, and many users have been asking for this for a long time. If a user wants to create a full ‘Evidence Explained’ (EE) set, it would also be an enormous contribution.
Switching Styles or Source Types: Just like modern bibliography software, if a user switches from a rich style to a ‘leaner’ one, or changes the Source Type, any unused fields should still be visible as key-pairs, or a ‘Discard fields’ prompt should appear. Crucially, no data is deleted from the database; the ‘discard’ only applies to what is excluded from the current style. If the user switches back to a richer style, the keys and data remain available in their respective fields.
Storage and Export: This mapping logic should not be written back to the CSL file, unless the user is specifically using a Gramps-specific CSL style. By default, it stays within Gramps and is exported to the Gramps XML.
The strength of CSL is its resilience. If we export a rich Gramps-generated file and open it in other software, the data isn’t lost—most programs will move unrecognized fields into a ‘note’ or ‘extra’ field. For example, Zotero adds them as key-pairs to the ‘Extra’ field. This allows Gramps to have a complex, hierarchical system while remaining a ‘good citizen’ in the wider ecosystem.
Note: I am fully aware that this is no small task. Although I am not a developer or a code architect, I understand the complexity and logic required for such a system. I am not able to write a direct technical specification, but I am trying my best to outline how I imagine this system could function to best support both users and interchangeable data between different research tools, based on my knowledge of these systems.
Note on translation: Parts of this text were drafted in Norwegian and translated and refined with the assistance of Google AI. The final content has been reviewed and approved by me.
