Interchangeable Dashboards (or Dashboard collection view modes)

I am glad that that the Gramplets view (introduced in version 3.0) evolved into View sidebar & bottombar split screens in version 3.3. But, in some ways, this massive improvement orphaned the newly rechristened Dashboard view. Its purpose became less obvious.

Perhaps Gramplet layouts oriented around a purpose could be saved & swapped as needed:
a ‘Welcome’ layout, a Database status layout, a Tree diagnostic layout, a session management layout, et cetera ad nauseam.

The Dashboard might be re-invigorated by giving it these variations of Modes. (The multiple named Configurations could be saved as Modes.)

Maybe the another pop-up contextual menu option (after the ‘Restore a Gramplet’) could be ‘Restore a layout’? Or options could be added to the ‘Layout’ tab of the Config for Saving, selecting, Renaming & Deleting a named layout? With the initial layout being named “Getting Started” And all that does is swap named variations of the Gramplets_dashboardview_gramplets.ini file in the Gramps51 sub-folder of the User Directory

However, to avoid the agony that we have in sharing Custom Filter definitions, perhaps the interface could allow each Named Gramplets_dashboardview_gramplets.ini chunk to be shown as a Copy & Paste text chunk in the GUI? Then I could copy a Dashboard configuration shared in this forum and paste it for use in my Gramps.

(And maybe in the future, since Gramps installs with a huge set of icons in the Adwaita theme, perhaps the Mode icon for the Toolbar could be selectable? Perhaps from a Media Preview style window that shows thumbnails of all the icon subfolders in the appropriately-sized-for-the-toolbar found in C:\Program Files\GrampsAIO64-5.1.3\share\icons\Adwaita\)

As an example, the following Gramplets_dashboardview_gramplets.ini is somewhat useful for managing your session:


;; Gramps gramplets file
;; Automatically created at 2021/03/03 09:17:25

[Gramplet View Options]
column_count=3
pane_position=-1
pane_orientation=horizontal

[To Do]
name=To Do
height=300
expand=True
title=To Do-1
detached_width=400
detached_height=300
state=maximized
page=0
help_url=None
navtypes=['Dashboard']
column=0
row=0

[Latest Changes]
name=LastChangeGramplet
height=175
expand=False
title=Latest Changes
detached_width=400
detached_height=300
state=maximized
page=0
help_url=LastChange
navtypes=[]
column=1
row=0

[What's Next?]
name=What's Next
height=230
expand=True
title=What's Next?
detached_width=400
detached_height=300
state=maximized
page=0
help_url=None
navtypes=[]
column=1
row=1

[Session Log]
name=Session Log
height=230
expand=True
title=Session Log
detached_width=400
detached_height=300
state=maximized
page=0
help_url=None
navtypes=[]
column=2
row=0

The default is:

;; Gramps gramplets file
;; Automatically created at 2021/03/03 09:22:19

[Gramplet View Options]
column_count=2
pane_position=-1
pane_orientation=horizontal

[Top Surnames]
name=Top Surnames
height=230
expand=False
title=Top Surnames
detached_width=400
detached_height=300
state=maximized
page=0
data[0]=10
help_url=None
navtypes=[]
column=0
row=0

[Welcome to Gramps!]
name=Welcome
height=300
expand=True
title=Welcome to Gramps!
detached_width=400
detached_height=300
state=maximized
page=0
help_url=None
navtypes=[]
column=1
row=0

It seems like there is a good argument for having reusable layouts in the Dashboard.

Initially, Gramps has a few introductory gramplets and I have to restore it for screen shots. But I often want a layout with a set of Statistics gramplets.

Or Date related Gramplets:

And other times, I need a set of Isotammi Gramplets.


Or I might configure a panel of 4 complementary QuickViews.

Changing between these layouts is tedious and fussy.

So if there was a toolbar control (similar to the Custom Type combo control) that selected between named layouts in the Gramplets_dashboardview_gramplets.ini file (or allowed a New Layout Name to be entered… which clones the current layout under that name) then the power of the dashboard would be greatly expanded. A context menu could be added to the indicator to the left which allows a layout to be removed or reset to default for any built-in named layouts.

The context menu might include an explicit Column count control … so the Configure could just be limited to the Gramplet configurations options.

Creators of new Dashboard views (like @cdhorn 's CardView could leverage the control to maintain multiple configurations too… or opt to stay with their own configuration controls.

How about an initial layout with 3 columns and the center column blank. Since the odd vacancy draws attention, the rollover hint in the center indicates that Gramplets can be added … and how to do so.

I agree that there are different times when different sets of dashboard gramplets would be useful. I would be happy if some of them (for example, Date Calculator) were things that I could simply launch from the Tools menu whenever I need them.

In addition to the uses you’ve laid out, another is to set up Gramps in the same way for multiple users. Having the same setup initially allows each person to see the same UI allowing easy explanations of how to accomplish tasks.

Christian W. Schulze did something similar in 2020 when contributing the Place Coordinate gramplet view. Which is a view mode for the Geography category which defaults to having his Place and Coordinates gramplet in the sidebar. The view is mostly a palette for the gramplet.

He wanted a view mode that complemented a specific purpose: refining the Place list with visual feedback.

Perhaps a developer could contribute a simple empty Dashboard view mode as an addon as a baseline.

@cdhorn noted some problems configuring a default view mode without the sidebar and bottombar active. So including that in the baseline would be helpful.

Can the default number of columns be different than the number in the original Dashboard 2?

Two other wishlist items would be:

  1. a “Help” (linked to the .gpr.py help_url) or “Configure” button linked to the View → Configure… action
  2. the ability to default to adding a new Gramplet in the collapsed state.

I turned Claude AI loose on this idea. It came up with a prototype replacement for the core Dashboard but with extravagant overengineering.

All this feature really needs is Dashboard view mode that copies the Dashboard_dashboardview.ini to a subfolder and overwrites it from another file in that subfolder.
When you Navigate back to base Dashboard mode, the different .ini will be used.

I really like the basic idea. Although “mode” isn’t the right word. I think selecting from a set of named dashboards would do it.

The reason I was going with a ‘view mode’ implementation was two-fold:

  1. the big glitch with the over-engineered version was refreshing a current view with the replacement .ini data. There wasn’t another feature in Gramps that did the necessary housekeeping. But if you switch view modes, Gramps took care of all the .ini reload and refresh work.
  2. It could be implemented as an Addon. So a more dynamic release evolution than the core release cycle supports.

The Card view adds another Dashboard as an addon. A ‘Dashboard xx’ view could be added as another addon. It will create its own set of ini files. Could it be pre-loaded with gramplets?? The ini files store the gramplet information. Could the ini files be stored with the addon??

I have a number of gramplets on my dashboard. I keep them all minimized until needed. This allows more gramplets stored neatly.

The word “mode” should not have any impact on implementation details. But using that word can effect the interface (and how we describe it), and I don’t think it is the right word for that.

Could you expound upon that?

In the User Guide, there are View Categories and view modes within those view categories. (see the V subsection of the Gramps Glossary for definitions and links to the related introductory section in the manual.)

Are we discussing the same ‘modes’?

Now I see the analogy you are making between a particular view, and those variations that we call “modes”.

But I think this is a different thing, requiring a different interface. I imagine that “dashboard” is a plugin type, and you can select which one is currently active/visible among all of those installed (defaulting to just the one if no others are installed).

Very possibly. I was thinking that this could start with the basics we are discussing … even though they are probably small enough to be implemented as a Config screen.

But it could evolve into a full Gramplet palette manager. That scope it too broad before we determine if a Dashboard palette manager can convert that view from a feature users have requested be disabled into something indispensable.

For instance, it is currently difficult recollect whether you’ve cleared a particular Gramplet from all the .ini files across all the view modes in all the view categories, not just the Dashboard view category. With a view mode established for managing the Gramplet sets of the Dashboard, the next expansion could add Sets across all the Categories. Or searching for a Gramplet that needs to be removed because it is running in the background or affecting stability. Or merely flushing .ini setting saved for a particular Gramplet instance.

Because there are 12 categories with 31 view modes (before the CardView addon), each having a Sidebar and a Bottombar; it is quite a chore to review them all. Generally, when I have a gramplet problem, it is often easier to simply delete all the related splitbar .ini files.

In creating a second Dashboard view as an addon, I discovered that the view’s gramplets are not stored in Dashboard_dashboardview.ini but in Gramplets_dashboardview_gramplets.ini. The main view ini file only contains the number of columns set.

Does it really make sense that every “mode” of a view has its own sidebar and bottom bar versions? That is too complicated, IMHO.

That sounds like a good thing to question. And the proliferation of customizations is really hard manage. (Which includes not only gramplet sets but also window position/sizes and column width customizations.) So it is an important question too.

But how would your reduce to a lowest common denominator when some gramplets make sense for some view modes but not others?

I regularly maintain different gramplet sets in the People List and Grouped views. And also in the Place list and grouped. And I switch back and forth between view modes to access the different sets of gramplets when 2 gramplets are not enough and a 2nd screen isn’t available for undocking some Gramplets. And each of the Geography view modes visualizes different data. So different gramplets (quickview gramplets in particular) provide more value in certain Geography view modes. Sometimes the main difference is that some gramplet data is better suited to portrait or to landscape. So one view mode could have the splitbar expanded to half the screen and the opposite splitbar disabled. The other view mode would be the reverse.

Different Filter gramplet settings are a prime example. It is helpful have the flat list mode filtered to target a worklist, using that list for active record navigating. And leave the grouped mode unfiltered to navigate to adjacent/related records. Having the Filter gramplets synchronized would slow down walking through for manual harmonizing.

Given that we are trying to make Gramps easier to use, and yet also simplify the crazy amount of complexity we currently have, I think we can find a compromise.

What if each “mode” remembered which gramplets were selected? Then as you switched between, say, grouped and ungrouped modes, the active gramplets (bottom and side) would switch? This would give you pretty much the same experience that you have today (you just need to have all the gramplets added to the side/bottom bars).

Things that really bother me about the current design:

  1. Switching modes changes the sidebar width
  2. Switching modes makes me have to renter the filter
  3. I have to add all of the gramplets that I want for each mode
  4. Which mode has the set of gramplets I like? I can’t remember

This is a large cognitive burden for little to no gain.

I agree … for the most part.

(Of 2 minds about #1. The shifting split bar height/width sometimes annoys and sometimes is useful… Except when a long Place or Person Name pushes the split width to be more narrow. That ALWAYS annoys me.)

And no potential solutions immediately suggest themselves for public brainstorming.

I’d love to hear feedback from some of our lurkers? This is an open invitation to throw out any and all ideas. Lets discover together what sticks against the wall!

(But be prepared. The most effective brainstorming requires bashing every suggestion from all directions. Accept that there are no perfect solutions. And finding holes early allows designing more seamless plugs.)

I have to say, for me this is a game changer. I would always lose track of what I was working on when I switched “modes” and really was a completely different view with the sidebars and bottom bars changing width, height and contents. Switching modes should not cause a complete context switch.

Here you can see what it looks like if the side and bottom bars stay the same when you switch between People (flat) and Grouped People:

Screencast from 04-01-2026 09:14:05 AM