Do not shadow focused text entries' Ctrl+C in list views

[eduralph]

Summary

User impact: In any list view (People, Families, Events, Places, and so on), clicking into the sidebar or filter search box, selecting some text, and pressing Ctrl+C does not copy that text. Instead Gramps copies the highlighted list entry into its own clipboard and pops up the Clipboard window. Cut and paste work normally in the same box — only copy is hijacked, which blocks ordinary copy-and-paste while a list is open.

This makes a focused text box own Ctrl+C so it copies your selected text, while the list still copies the selected object when the list itself has focus.

Reported in Mantis #6170.

What to look at

The whole change is one focus check added to the shared list-view Ctrl+C handler: if a text box has focus, let the keystroke through to it instead of copying the selected list object. To try it:

1. Open the People view and select a person (so object-copy has a target).
2. Click into the sidebar/filter "Name" entry, type any text, and select it (Ctrl+A).
3. Press Ctrl+C — pre-fix: the Clipboard window opens and the person is copied (text not copied); post-fix: no Clipboard window, the text lands on the system clipboard.
4. Click the person list row and press Ctrl+C — before and after, the person is copied to the Gramps Clipboard (object-copy preserved).

Root cause

PageView.__init__() at pageview.py:131 connects the key_press_handler to the toplevel window:

self.uistate.window.connect("key-press-event", self.key_press_handler)

GTK delivers key-press events to the toplevel before the focused child widget, so a window-level handler runs first. NavigationView overrides this handler and, for Ctrl+C, unconditionally invokes call_copy() and consumes the event (return True at lines 487–489):

if event.keyval == Gdk.KEY_c and match_primary_mask(event.get_state()):
    self.call_copy()
    return True

The return True stops propagation, so a focused sidebar/filter entry never sees Ctrl+C. call_copy() then opens a ClipboardWindow when a list object is selected, which is why the symptom is "Ctrl+C pops up the Clipboard."

Fix

Before invoking object-copy, NavigationView.key_press_handler (gramps/gui/views/navigationview.py:481–490) checks whether the focused widget is a text-editable. If it is, return False to let GTK propagate the event to the focused editable, which performs standard text copy to the system clipboard. The fix (lines 488–498) is:

# Do not shadow the standard Copy of a focused
# text-editable widget (e.g. a sidebar/filter entry).
# The focused editable owns Copy/Cut/Paste, so let the
# key event propagate to it instead of copying the
# selected list object to the Gramps clipboard.  The
# object copy is still performed when the list/tree
# itself (not a text entry) holds the focus.  (Mantis
# #6170)
focus = self.uistate.window.get_focus()
if isinstance(focus, (Gtk.Editable, Gtk.TextView)):
    return False
self.call_copy()
return True

This restores the invariant that a window/view-level accelerator must not shadow the standard text-editing keystrokes of a focused text-editable widget. The fix lives in the shared NavigationView.key_press_handler, so it holds for all navigation list views (People, Families, Events, Places, Sources, Citations, Repositories, Media, Notes), not a single view.

Verification

• Claim: The patch lets focused text-editable widgets own Ctrl+C, while list/tree focus still copies the selected object.
• Checked: gramps/gui/views/pageview.py:131 (connects key_press_handler to the toplevel window) and gramps/gui/views/navigationview.py:481–490 (the handler override) on maintenance/gramps61 — the fix (lines 488–498) checks focus type before call_copy() at line 499 (unchanged). Gtk.Editable/Gtk.TextView are the standard GTK text-editable base types; all sidebar/filter entries (e.g. _searchbar.py:57 builds a Gtk.Entry) are Gtk.Editable instances, so returning False lets the event propagate to them. Object-copy is preserved because the isinstance(focus, (Gtk.Editable, Gtk.TextView)) check returns False for a Gtk.TreeView, so call_copy() (line 499) and return True (line 500) execute unchanged.
• Test: No core unit test ships — the behaviour is GUI focus/event-propagation, not headless-testable. Coverage is a committed AT-SPI/dogtail regression in the gramps-testbed harness (not part of this PR), engine/interface/test_bug_0006170_sidebar_filter_copy.py, which asserts no top-level "Clipboard" frame appears after Ctrl+C in a focused sidebar entry — red on the unpatched target (the Clipboard window appears and the handler consumes Ctrl+C), green with the patch. Manual repro: People view → select a person → focus the sidebar Name entry → type and select text → Ctrl+C copies the text to the system clipboard.

Fixes #6170