# Making event label visible

**URL:** <https://gramps.discourse.group/t/making-event-label-visible/9801>\
**Category:** Ideas\
**Created:** [August 4, 2026, 2:14pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801 "2026-08-04T14:14:52Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![ursus](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/ursus/32/5975_2.png) [@ursus](https://gramps.discourse.group/u/ursus)\
**Post date:** [August 4, 2026, 2:14pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/1 "2026-08-04T14:14:52Z")

</div>

in person category I can give the person a label and make it visible as a column  
When I ad an event to the person I can give the event a label but it isn’t visible in the event-list that is in de same layout. [person-category \> events]  
It seems it is only visible from within the events category or when I open up that specific event.  
Is it possible to make the label of the event visible from the event-list within the person category?  
Win 11  
AIO64-6.0.8–1

 ![2026-08-04 16 12 48](https://global.discourse-cdn.com/free1/uploads/gramps/original/2X/f/fdb6e5ad14c14530537fdf5931890d3feb0f45ef.jpeg)

---

<div class="post-metadata">

**Author:** ![DaveSch](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/davesch/32/40_2.png) [@DaveSch](https://gramps.discourse.group/u/DaveSch)\
**Post date:** [August 4, 2026, 5:17pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/2 "2026-08-04T17:17:47Z")

</div>

You can.. unless we are talking about different things.

 ![EventsCategory-EventsView-Configure-dialog-default-60](https://global.discourse-cdn.com/free1/uploads/gramps/original/2X/c/c1f967c2c145c298b489a7ec48f65e4d96877f0c.png)

---

<div class="post-metadata">

**Author:** ![DaveSch](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/davesch/32/40_2.png) [@DaveSch](https://gramps.discourse.group/u/DaveSch)\
**Post date:** [August 4, 2026, 5:35pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/3 "2026-08-04T17:35:04Z")

</div>

And we are talking about different things.

You want the Tags of an event to appear in the Events gramplet for the People and Families views!!!

---

<div class="post-metadata">

**Author:** ![ursus](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/ursus/32/5975_2.png) [@ursus](https://gramps.discourse.group/u/ursus)\
**Post date:** [August 4, 2026, 5:44pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/4 "2026-08-04T17:44:29Z")

</div>

Correct Dave, Not what the upper arrow indicates, but the lower one in this screendump.  
Is it possible?

 ![2026-08-04 19 35 13](https://global.discourse-cdn.com/free1/uploads/gramps/original/2X/f/f35c867c3171ec8b45e74d48af990f1a19b16a88.jpeg)

---

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [August 4, 2026, 5:59pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/5 "2026-08-04T17:59:42Z")

</div>

> [@ursus](#):
>
> Is it possible?

You would have to hack the Events gramplet since those gramplets do do not have the optional column selector and ordering which is offered in the Configure for list view modes.

But you could use the Events category list view as a template for adding another column.

---

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [August 4, 2026, 7:23pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/6 "2026-08-04T19:23:34Z")

</div>

> Expanded @ursus idea and asked Claude to propose a Events+ addon gramplet:

# “Events+” Gramplet — Design Document

**Status:** Design/feasibility — not yet implemented.  
**Reference sources (gramps-project/gramps@master):**  
`gramps/plugins/view/eventview.py`, `gramps/gui/views/treemodels/eventmodel.py`,  
`gramps/gui/views/listview.py`, `gramps/gui/views/pageview.py`,  
`gramps/gen/utils/configmanager.py`, `gramps/plugins/view/relview.py`,  
`gramps/plugins/gramplet/citations.py`, `gramps/plugins/view/view.gpr.py`,  
[`kkujansuu/gramps/add-multiple-events`](https://github.com/kkujansuu/gramps/tree/master/addons/add-multiple-events)

## 1. Goal

A gramplet, embeddable in the Person, Relationships, Families, and Place views’ sidebar/  
bottombar, that has the same layout as the Events Category (an Events-view-style list) — same columns, same order, same widths, same context-menu actions — but pre-filtered to the events relevant to the host view’s current object(s) instead of the whole database.

Added functionalities:

- adds `ID`, `Private`, `Tags`, `Last changed` column access to current : Type, Description, Date, Age, Place, Main participants, Role
- context menu actions: Add, Edit, Delete, Merge, QuickView
- extended selection
- Copy to clipboard
- drag’n’drop support

## 2. Non-goals / explicit constraints

- No separate toolbar inside the gramplet.
- No “Configure” tab for the gramplet itself — it always mirrors the Events view’s own column configuration.
- No new filter UI — filtering is driven entirely by the host view’s active  
object(s), not by a `EventSidebarFilter`.

## 3. Base class

Subclass `Gramplet` (`gramps/gen/plug/_gramplet.py`), not `ListView`/`PageView`.  
`ListView` bundles a `Gtk.UIManager`, action groups, and toolbar XML that a  
Gramplet host does not own and should not try to acquire. Build a plain  
`Gtk.TreeView` in `build_gui()`, following the pattern already used by core  
gramplets such as `Citations` (`gramps/plugins/gramplet/citations.py`).

```python
selection = self.treeview.get_selection()
selection.set_mode(Gtk.SelectionMode.MULTIPLE)

```

gives extended selection with no custom code.

## 4. Row model: reuse `EventModel` via `skip`, not a new filter class

`EventModel(db, uistate, skip=set())` already implements cursor iteration, column mapping (including the cached `Main Participants` column), and sorting for every column the Events view exposes. Its `skip` parameter is a set of handles to _exclude_.

Reuse strategy:

```python
all_handles = set(db.get_event_handles())
wanted = self._compute_wanted_handles() # context-specific, see §6
skip = all_handles - wanted
model = EventModel(db, uistate, skip=skip)

```

This reuses the entire row-building/sorting pipeline unmodified. No new `Rule`/`GenericFilter` subclass is needed, and none should be written — that would duplicate logic `FlatBaseModel` already owns.

Rebuild the model (new `skip` set) whenever:

- the host view’s active object changes (`active-changed` signal), or
- an `event-add` / `event-update` / `event-delete` / `person-update` / `family-update` signal arrives (same `signal_map` entries `EventView` already registers — reuse the same dict).

## 5. Column configuration sync

`PageView.init_config()` calls:

```python
self._config = config.register_manager(self.ident, use_config_path=True)

```

`register_manager()` stores the `ConfigManager` in a **global, class-level  
registry**: `ConfigManager.PLUGINS[name]`. This means:

- If the Events view has already been instantiated this session, calling `config.get_manager("gramps.plugins.view.eventview")` returns **the same live object** the Events view reads and writes. `ConfigManager.connect(key, func)` can subscribe directly to `columns.visible` / `columns.rank` / `columns.size` changes for true same-session live sync.
- `register_manager()` has **no “already registered” guard** — it always creates a new `ConfigManager` and overwrites the global slot. If the gramplet calls it before the Events view has ever been opened this session, and the Events view is opened later, the Events view’s own`self._config` reference is a _different_ Python object than the one the gramplet cached earlier — they will drift apart.

**Recommended pattern:**

```python
def _get_event_view_config():
    ident = "gramps.plugins.view.eventview"
    try:
        return config.get_manager(ident)
    except AttributeError:
        # Events view not instantiated yet this session — read-only,
        # do NOT call register_manager() (would collide with the
        # real view's later registration).
        return _read_only_config_from_ini(ident)

```

Never cache the manager reference across rebuilds — refetch immediately before reading columns. The lookup is cheap (dict access), and refetching sidesteps the load-order hazard entirely.

## 6. Context filtering per host view

### 6a. Person view

```python
wanted = set(h.ref for h in person.get_event_ref_list())
for fam_handle in (person.get_family_handle_list()
                   + person.get_parent_family_handle_list()):
    family = db.get_family_from_handle(fam_handle)
    wanted.update(h.ref for h in family.get_event_ref_list())

```

Covers personal events, events of families where the person is a parent, and events of families where the person is a child.

### 6b. Place view

```python
wanted = set(
    handle for (obj_class, handle) in
    db.find_backlink_handles(place.handle, include_classes="Event")
)

```

This is the same `find_backlink_handles` call `EventView.tag_updated()` already uses internally — direct reuse, not reinvention.

_Open design question (not blocking):_ whether to also include events of places enclosed by/enclosing the active place via `PlaceRef` hierarchy.  
Recommend v1 = exact place only, matching the literal spec.

### 6c. Relationships view — two options, decide during implementation

`RelationshipView.collapsed_items` (in `relview.py`) is a **plain, private, non-persisted, per-instance dict** — no public getter, no signal on toggle, does not survive between sessions. This is the one part of the spec that doesn’t map onto an existing public API.

**Option A — introspect now (fragile, works today)**

Reach `uistate.viewmanager` to find the live `RelationshipView` instance for the active person’s category page, and read `collapsed_items` / `check_collapsed()` directly to determine which families/people are currently expanded.

- Pro: matches the spec exactly, works immediately.
- Con: depends on a private attribute name/shape that isn’t part of any contract; a `relview.py` refactor silently breaks this gramplet with no deprecation warning; likely to draw review pushback if ever proposed for gramps-project/addons-source or core.

**Option B — scoped v1 + upstream API follow-up (robust)**

v1 shows events of the active person + their immediate families (as parent and as child) — same computation as §6a — regardless of what’s actually expanded/collapsed in the Relationships view’s UI. True expand-state tracking becomes a follow-up patch that adds to `relview.py`:

```python
def get_expanded_families(self):
    """Return handles of families currently shown expanded."""
    ...

# emit a signal (or call a registered callback) from
# expand_collapse_press() so listeners can react live

```

- Pro: no dependency on private state; a clean, reviewable upstream contribution that benefits any future consumer, not just this gramplet.
- Con: v1 relationships-view filtering is coarser than the original spec until the upstream piece lands.

**Recommendation:** prototype with Option A locally to validate the rest of the design (columns, menu, add/merge) end-to-end, but plan to submit Option B’s small `relview.py` API addition upstream before proposing Events+ for inclusion in `addons-source`. Decide which ships in v1 once the rest of the gramplet is working and it’s clear whether the upstream patch is likely to land in a reasonable timeframe.

### 6d. Families view

The active object here is a `Family`, not a `Person`, so the wanted set is built directly from the family and its two parents — no backlink lookup or private-state introspection needed, unlike §6b/§6c:

```python
family = db.get_family_from_handle(active_family_handle)
wanted = set(h.ref for h in family.get_event_ref_list())

for parent_handle in (family.get_father_handle(), family.get_mother_handle()):
    if parent_handle:
        parent = db.get_person_from_handle(parent_handle)
        wanted.update(h.ref for h in parent.get_event_ref_list())

```

This covers the family’s own events (e.g. Marriage, Divorce — attached via `Family.event_ref_list` with `EventRoleType.FAMILY`, per §8.2’s attachment convention) plus each parent’s personal events (Birth, Death, etc.).

_Open design question, same shape as the Person-view one in §6a:_ whether to  
also include the **children’s** personal events. The literal spec text for this view (family members’ events) doesn’t explicitly rule children in or out the way §6a’s “child or parent” wording does for the Person view.  
Recommend v1 = family + both parents only, matching the Family-context variant of `add-multiple-events` (§8.1), which likewise scopes to Father/Mother/Children as attachable _targets_ for sharing but doesn’t imply children’s own personal events belong in an at-a-glance Family event list.  
Children’s events remain one filter checkbox/toggle away if this proves too narrow in practice — not a blocking decision for v1.

Signal wiring mirrors §6a: rebuild on `active-changed` for the `Family` navigation type, plus the same `event-*`/`family-update`/`person-update` entries from `EventView`’s `signal_map` (family and parent-person changes both need to trigger a re-filter, since either can add/remove an event from the wanted set without an `event-*` signal firing on its own).

## 7. Context menu — cannot literally reuse the Events view’s UIManager XML

`win.Add` / `win.Edit` / `win.Remove` / `win.Merge` in `eventview.py`’s `additional_ui` are actions on the **main window’s action group** , which is swapped per-category by whichever View is currently active. A gramplet embedded in, say, the Person view does not own that action group — the Person view does. Invoking `win.Add` from inside the gramplet would add a _Person_, not an Event.

**Resolution:** build a small hand-rolled `Gtk.Menu` inside the gramplet (right-click + Menu key), mirroring the Events view’s Popup section:

- Add…, Edit…, Delete, Merge… — same labels/icons as `eventview.py`.
- Sensitivity rules, dimmed per selection count:
  - Edit: enabled for 1+ rows.
  - Delete: enabled for 1+ rows.
  - Merge: enabled **only** when exactly 2 rows selected (matches `EventView.merge()`'s existing requirement verbatim).
  - Add: always enabled; behavior depends on number of _context targets_, not treeview row selection (see §8).

Every action underneath is fully reused: `gui.editors.EditEvent`, `gui.merge.MergeEvent`, `remove_selected_objects`-equivalent handle-based deletion, tag add/remove via `db.commit_event`. Only the _menu wiring_ is new; none of the underlying editors/dialogs/transaction logic is reimplemented.

## 8. “Add & share” across multiple context targets

“Target” here means the Person/Family objects providing the filter context — not rows in the gramplet’s own treeview. This matters most in the Relationships-view case, where multiple families/people can be in context simultaneously.

### 8.1 Prior art: `kkujansuu/gramps/addons/add-multiple-events`

`add-multiple-events.py` (Kari Kujansuu, GPL-2.0-or-later, same author as the Isotammi addons) is a `QUICKREPORT` registered against `CATEGORY_QR_FAMILY` and `CATEGORY_QR_PERSON` that solves a closely related problem: sharing one event across a Family’s Father/Mother/Children, or across a Person’s parents/spouses/children. Several of its patterns are worth adopting directly, one detail should be deliberately **not** copied, and one behavior differs from what this spec actually asks for.

**Adopt:**

- **Opt-out checklist, not a blind broadcast.** It builds a pre-checked `Gtk.CheckButton` per target (Father/Mother/Child/Spouse as applicable), plus a “check/clear all” toggle, and only applies the event to whichever boxes are still checked when the user confirms. Events+ should do the same for its multi-target Add: show the context targets as an opt-out list rather than fanning out unconditionally.
- **`EditEventRef`, not bare `EditEvent`** , for both creating a new event and attaching an existing one — it lets the user set/confirm the Role at the same moment, via `EditEventRef(dbstate, uistate, [], event, ref, callback)`.  
This is a better fit than editing the Event and assigning roles as a separate step.
- **Two entry points, one callback** : “Select Event” (`SelectorFactory ('Event')`, then `EditEventRef` to attach a role) and “New Event” (blank `Event()` with `event.new_event = True`), both funneling into the same `eventref_callback(eventref, event)`.
- **Persisted defaults** : `config.register_manager("events-plus")` with keys for last-used event type/role/place, so repeated “Add & share” actions don’t require re-picking the same type/role every time. Mirrors §5’s `ConfigManager` usage, just a separate manager/ident for the gramplet’s own transient state (not the Events-view column config, which must stay untouched per §5).

**Do not adopt:** the addon’s runtime widget surgery to detect “am I a real Quick View dialog or embedded in the Quick View gramplet host” (swapping `TextView`/`ScrolledWindow`/`VBox` contents at runtime). That workaround exists only because a `QUICKREPORT` is being retrofitted into the generic Quick-View gramplet shell. Events+ is a `Gramplet` from the start (§3), so this entire class of hack doesn’t apply — build the `Gtk.TreeView`/dialog normally.

**Deliberate divergence — role assignment and attachment point:** the reference addon always resolves targets down to individual `Person` handles and always calls `person.add_event_ref()` — even when invoked from the Family context menu, `Father`/`Mother` are still attached as `Person`-level refs, never as a `Family.event_ref_list` entry. That’s a reasonable simplification for its own scope, but it does not match what this spec asks for (“share … using the Primary or Family event role **as appropriate** ”), which implies Family-object targets should get a `FAMILY`-role `EventRef` on the family itself, and Person-object targets a `PRIMARY`-role `EventRef` on the person. Events+ should keep the differentiated attachment from §8.2 below rather than the addon’s person-only simplification.

**Optional, not required for v1:** the addon supports both “share” (one `Event`, multiple refs) and “copy” (independent `Event` per additional target, with a `RESIDENCE`-specific date-clamping correction to the target’s birth/death range) via a `share` checkbox. The spec here asks for “share,” so v1 doesn’t need copy-mode, but it’s a documented option if a future iteration wants it.

### 8.2 Events+ implementation, incorporating the above

```python
event = Event()
ref = EventRef()
try:
    EditEventRef(dbstate, uistate, [], event, ref, cb_event_added)
except WindowActiveError:
    return

def cb_event_added(self, eventref, event):
    """Called by EditEventRef once the user confirms the new/selected
    event. Present the opt-out target checklist before committing refs."""
    self._show_target_checklist(event, context_targets)

# after the user confirms the (possibly trimmed) target list:
with DbTxn(_("Add shared event"), db) as trans:
    for target in confirmed_targets:
        eventref = EventRef()
        eventref.ref = event.handle
        if isinstance(target, Family):
            eventref.set_role(EventRoleType(EventRoleType.FAMILY))
            target.add_event_ref(eventref)
            db.commit_family(target, trans)
        else: # Person
            eventref.set_role(EventRoleType(EventRoleType.PRIMARY))
            target.add_event_ref(eventref)
            db.commit_person(target, trans)

```

This is the one piece of genuinely new orchestration logic in the whole design — everything it calls (`EventRef`, `EventRoleType`, `EditEventRef`, `DbTxn`, `commit_person`/`commit_family`) is stock `gen.lib`/`gen.gui`/`gen.db` API, and the UX shape (checklist, persisted defaults, two entry points) is lifted from a working, GPL-2.0-or-later precedent rather than designed from scratch.

## 9. Signals / live updates

Reuse `EventView. __init__ `'s `signal_map` dict verbatim as the basis for `dbstate.db.connect(...)` wiring inside the gramplet, plus:

- `active-changed` on the host view’s navigation type (Person/Place), via `Gramplet.connect_signal(nav_type, method)` — already built into the `Gramplet` base class.
- For Relationships view Option A only: whatever hook is used to observe `expand_collapse_press` (polling on `active-changed` is an acceptable fallback if no signal is available).

## 10. Risk summary

| Area | Risk | Mitigation |
| --- | --- | --- |
| Column sync | `register_manager` load-order race | Refetch via `get_manager` each rebuild; never cache long-term |
| Context menu | Can’t reuse `win.*` actions | Hand-rolled `Gtk.Menu`, same underlying editors |
| Relationships filter | Private, non-persisted state | Option A (fragile) vs Option B (scoped + upstream API) — decide at implementation time |
| Multi-target add | New orchestration logic | UX pattern (checklist, `EditEventRef`, persisted defaults) adapted from `kkujansuu/gramps/add-multiple-events`; attachment logic (Person vs Family role) is Events±specific, built on stock `EventRef`/`DbTxn` APIs |
| Merge | None | Verbatim reuse of `EventView.merge()` logic (exactly 2 selected) |

## 11. Phased plan

1. **v1 skeleton** : Gramplet + `Gtk.TreeView` + `EventModel` via `skip`, Person-view and Place-view filtering (§6a/§6b), config sync (§5), hand-rolled context menu (§7), single/merge actions.
2. **v1.1** : multi-target “Add & share” (§8).
3. **v2** : Relationships-view filtering — Option A prototype first, propose Option B’s `relview.py` API upstream in parallel, switch over once available.

## 12. AI-disclosure note (per project guidelines)

Per `Howto:_Contribute_to_Gramps#AI_generated_code`, once implementation begins: commit messages must name the AI tool/provider/version used, substantially-AI-written commits need a `Generated-by:` tag with an indication of the prompts used, and any AI-assisted review/pairing needs `Co-authored-by:`. This design doc itself should be referenced from the first implementation commit’s `Generated-by:` tag as the guideline document that was worked against.

---

<div class="post-metadata">

**Author:** ![ursus](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/ursus/32/5975_2.png) [@ursus](https://gramps.discourse.group/u/ursus)\
**Post date:** [August 4, 2026, 7:41pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/7 "2026-08-04T19:41:56Z")

</div>

O wow, not that I understand anything (or mostly not)

Just being proud on my own gram.py script I made  
All 390 lines of it. It does the job I wanted (Still wondering how to solve some things, like: is it possible the script will ‘know’ what the active person record is. Instead of me needing to fill it manually all the time…)  
So back to the answer to my question: ‘no, it is currently not possible to show the label where you want it’

---

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [August 4, 2026, 8:47pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/8 "2026-08-04T20:47:04Z")

</div>

> [@ursus](#):
>
> like: is it possible the script will ‘know’ what the active person record is. Instead of me needing to fill it manually all the time

You could look at some other Gramplets that track the **Active Person**.

The Deep Gallery gramplet by Hans Boldt @ukulelehans is a 7k of code example:

- [finding the handle of the Active Person](https://github.com/hgboldt/deepgallery/blob/c230198adc5d84f72d9dec12ec6e5c97ce7d83a2/deepgallery.py#L196-L200)
- basic [monitoring of the tree](https://github.com/hgboldt/deepgallery/blob/c230198adc5d84f72d9dec12ec6e5c97ce7d83a2/deepgallery.py#L167-L185) (using Signals and [Callbacks](https://gramps-project.org/docs/gen/gen_utils.html#module-gramps.gen.utils.callback)) for specific activity that might require a refresh.

mis-read the posting. Here’s the **gram.py** way to reference the Active record in the categories:

> [@New Gram.py Script for 6.0](https://gramps.discourse.group/t/new-gram-py-script-for-6-0/7192/8):
>
> > [@New Gram.py Script for 6.0](https://gramps.discourse.group/t/new-gram-py-script-for-6-0/7192/7):
> >
> > Even so, is **gram.py** aware of the currently active object(s) of each type, if any?
> 
> Yes, all of the active objects are defined (if a view is loaded), like **active\_person** , **active\_note** , etc.

---

<div class="post-metadata">

**Author:** ![ursus](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/ursus/32/5975_2.png) [@ursus](https://gramps.discourse.group/u/ursus)\
**Post date:** [August 5, 2026, 12:58pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/9 "2026-08-05T12:58:00Z")

</div>

Thank you Brian.

I managed to do that  
used: active\_handle = self.get\_active(‘Person’)  
and even slimmed the script down by 30 lines because of that.

---

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [August 5, 2026, 2:09pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/10 "2026-08-05T14:09:36Z")

</div>

> [@ursus](#):
>
> I managed to do that  
> used: active\_handle = self.get\_active(‘Person’)  
> and even slimmed the script down by 30 lines because of that.

Nice!

But if you are not going to to adapt your **Gramp.py script** to be wrapped in an addon interface, you would not need to “declare” it at all.

You could just use the Gram.py pre-declared `active_person` directly.

---

<div class="post-metadata">

**Author:** ![ursus](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/ursus/32/5975_2.png) [@ursus](https://gramps.discourse.group/u/ursus)\
**Post date:** [August 5, 2026, 2:19pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/11 "2026-08-05T14:19:59Z")

</div>

I am just mightily releaved I have managed this.  
Will look at this at a later date. Right. It works now..  
Thank you again.

---

<div class="post-metadata">

**Author:** ![dsblank](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/dsblank/32/3649_2.png) [@dsblank](https://gramps.discourse.group/u/dsblank)\
**Post date:** [August 5, 2026, 3:14pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/12 "2026-08-05T15:14:29Z")

</div>

> [@ursus](#):
>
> I am just mightily releaved I have managed this.

@ursus would you mind sharing your Gram.py script (if it doesn’t contain personal bits)? I don’t yet have many examples available for people. I am so happy you were able to write one!

---

<div class="post-metadata">

**Author:** ![ursus](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/ursus/32/5975_2.png) [@ursus](https://gramps.discourse.group/u/ursus)\
**Post date:** [August 5, 2026, 3:51pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/13 "2026-08-05T15:51:13Z")

</div>

I could do that,

But it is all geared to giving a result text in Dutch.  
what it does:

For the currently active person  
It checks if it a woman. (You’ll see why)  
Then checks if she has had children out of wedlock  
If so the scripts lists those children

It also checks if the woman got any children within  
280 after marriage (Average gestiation period)  
Displaying the number of days she was probably pregnant

Now I now the calculations used are not very scientific  
I wanted to know this to see if further (more exact) statistics would yield anything more valuable for the research object.  
Which includes number of children, ages gaps between children, age gaps between first and last, ages of parent (or both parents if both are known)  
And later correlation will follow between places where they live, income etc.  
But all these are in the future now.

So it is a tool for researchers (Two other databases other then mine are involved) to gain some insight if detailed research would be warranted or be a waiste of time and effort.

Also would you need it to be translated?  
And I wouldn’t want it being public right now.

Kind regards,  
Erik Appeldoorn

---

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [August 5, 2026, 3:54pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/14 "2026-08-05T15:54:38Z")

</div>

> [@ursus](#):
>
> And I wouldn’t want it being public right now.

You could share it with @dsblank via [_Discourse_ **Private Messaging**](https://meta.discourse.org/t/discourse-messaging-guide-for-new-users/154382/4). He could see if it inspires him to create any sample Gram.py scripts. Ones that are more broadly useful (and understandable, or inspirational) for the general public.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/gramps/original/1X/2ac1e712b7adf612e31ca08a55419f4cf37c0158.png) [@system](https://gramps.discourse.group/u/system)\
**Post date:** [September 4, 2026, 3:54pm UTC](https://gramps.discourse.group/t/making-event-label-visible/9801/15 "2026-09-04T15:54:45Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.