Idea for Roadmap 5.3 - Keyboard keybindings

[dlynch]

I propose:

• Enable use of all Gramps’ features, including the clipboards, using keyboard only, without mouse.

---

Nick.

That seems reasonable to me.

I suggest that you start by compiling a list of changes that need to be made.

From the Gramps wiki: “For an application like Gramps the Clipboard is very important as it will help reduce repetitive data entry.” The clipboard is indeed powerful, but currently using it is mouse-intensive. These proposals are aimed particularly at those who wish to reduce their mouse usage, perhaps because of repetitive strain injury, and those on platforms which don’t support drag.

Throughout, “clipboard” refers either to the clipboard tool or to the Collections Clipboard add-on. It is assumed that several of these are open simultaneously.

Throughout, suggestions for the exact key strokes invoking the proposed behaviour are just suggestions. Included are proposals to make the key strokes configurable.

The proposals are presented in rough order of importance.

 1  [Enter] should be equivalent to [OK]. There should be exceptions listed below (paragraph 13).
 2  [Ctrl-S] should switch the focus from the current window to the next window. By window, I mean any dialogs or clipboards. The new focus should be the same as when the window last had focus, and at the last field if it has never had focus.
 3  [Ctrl-D] should drag the item with focus to the appropriate window:
     3.1  If the focus is in a clipboard, and if the item is a:
         3.1.1  Citation, insert the item as the last citation in the last referenced dialog with a Citations tab, and change the focus to this dragged item. (If no such Citation tab exists, do nothing.)
         3.1.2  Event, insert the item as the last event in the last referenced dialog with an Event tab, and change the focus to the role field of this dragged item. (If no such Event tab exists, do nothing.)
         3.1.3  Place, insert the item as the place field in the last referenced dialog with a General tab, and change the focus to this field. (If no such General tab exists, do nothing.)
         3.1.4  Text, insert the item as the description field in the last referenced dialog with a General tab, and change the focus to this field. (If no such General tab exists, do nothing.)
         3.1.5  Source, insert the item in the Source Citations tab of the last reference dialog with a Source Citations tab, and change the focus to this dragged item. (If no such Source Citations tab exists, do nothing.)
         3.1.6  Repository, insert the item in the Repositories tab of the last reference dialog with a Repositories tab, and change the focus to this dragged item. (If no such Repositories tab exists, do nothing.)
         3.1.7  Person or Family, do nothing.
     3.2  If the focus is not in a clipboard, copy the item to the last referenced clipboard. (Do not change focus.)
 4  [Ctrl-T] should change the focus within a window: 
     4.1  For dialogs with a top and bottom halves, it should toggle the focus from top to bottom, or from bottom to top of dialogs. The focus should be changed to be on the field that last had focus, or if no such field, the first in the top half and the last in the bottom half.
     4.2  For windows with a find field: if the focus is in the find field, it should toggle the focus to the field (other than the find field) that last had focus, or if no such field the first one (other than the find field), and if the focus is not on the find field it should toggle the focus to the find field.
     4.3  For windows with a side bar and/or bottom bar, it should cycle around these and the display area, The focus should be changed to be on the field that last had focus, or if no such field, the first field.
 5  The arrow keys should move focus within the relationship and chart views:
     5.1  The name of the person in focus should be highlighted.
     5.2  The focus should initially be on the active person or, if no active person, the top person in the display area.
     5.3  [right-arrow] should move focus to the next person in the display area.
     5.4  [Enter] should open the person dialog for the person in focus, change the active person to this person, **but not change the person at the top of the display area, or any other part of the display area**. 
     5.5  [Ctrl-Enter] should open the person dialog for the person in focus, change the active person to this person, and **reconfigure the display area** with the active person at the top.
     5.6  [down-arrow] should move focus to the first person in the next family.
     5.7  [left-arrow] and [up-arrow] should work similarly but backwards.
 6  If the focus is on a person (in relationship and chart views), or a citation (in an event editor) or an event (in a person editor), or any item in a clipboard, then [Cntl-up-arrow] and [Ctrl-down-arrow] should move the items up or down, where possible.
 7  Accelerator [Alt+] Keystroke Assignments for each dialog should enable movement to each field with a single keystroke. (No omissions or duplicates.)
 8  The initial focus on opening the edit person dialog for **existing** persons should be the last event in the Personal section of the Event tab.
 9  [Alt-Q] should open the context menu with the focus on the first item.
 10  In the Person Dialog:	
     10.1  [Ins] should open a new event dialog for whichever of Birth, Death and Burial does not already exist. If all exist, open a new event with the focus on event type.
     10.2  [Alt-?] should open a new event of type Baptism, Christening, Census, Occupation, or Residence where ? Is B, C, X, O or R.
     10.3  The focus (excluding the exception above) should be on the date.
 11  In the Family dialog, [Ins] should open a new event of type Marriage in the Events tab, with the focus on date.
 12  In the Events dialog, [Ctrl-Enter] should save the event with the role Primary.
 13  In all of the select menus (Event, Place, Source, Citation, Repository, Media or Note), if there is precisely one item in the display area, [Enter] should select this item (even if the item is not in focus).
 14  [Ctrl-Esc] should Close without Saving when this is an option.
 15  The keyboard shortcuts and accelerator assignments should be configurable by the user.
 16  A default set of keyboard shortcuts and accelerator assignments should be available based on Language.

This is a first stab at enabling building an existing tree, mouse free. It does not include starting a new tree, correcting mistakes in a tree and producing reports. I am not authorised to put this in the Roadmap Category of Discourse, so have put it ideas instead.

David Lynch

[emyoulation]

Let’s start with the existing Keybindings. We could flag what is inconsistent within Gramps and with OSes.

For example:

• Internal: Ins (aka Insert) and Ctrl + Ins keybinding are both used (in different contexts) for “Add”. (Since Ins is a standard OS mode switch for Insert/Overwrite modes in Text Editing, Gramps should probably standardize on Ctrl + Ins.)
• OS: the standard Ctrl + C is high-jacked for the internal Clipboard and sacrificing inter-application copy & paste.

Then list out what’s is missing for full keyboard accessibility.

[dlynch]

My original post was truncated, reposted:
I propose:

• Enable use of all Gramps’ features, including the clipboards, using keyboard
  only, without mouse.

---

That seems reasonable to me.

I suggest that you start by compiling a list of changes that need to be made.

Nick.

From the Gramps wiki: “For an application like Gramps the Clipboard is very
important as it will help reduce repetitive data entry.” The clipboard is indeed
powerful, but currently using it is mouse-intensive. These proposals are aimed
particularly at those who wish to reduce their mouse usage, perhaps because
of repetitive strain injury, and those on platforms which don’t support drag.

Throughout, “clipboard” refers either to the clipboard tool or to the Collections
Clipboard add-on. It is assumed that several of these are open simultaneously.

Throughout, suggestions for the exact key strokes invoking the proposed behaviour
are just suggestions. Included are proposals to make the key strokes configurable.

The proposals are presented in rough order of importance.

 1  [Enter] should be equivalent to [OK]. There should be exceptions listed
 below (paragraph 13).
 2  [Cntl-S] should switch the focus from the current window to the next
 window. By window, I mean any dialogs or clipboards. The new focus should
 be the same as when the window last had focus, and at the last field if
 it has never had focus.
 3  [Cntl-D] should drag the item with focus to the appropriate window:
     3.1  If the focus is in a clipboard, and if the item is a:
         3.1.1  Citation, insert the item as the last citation in 
		 the last referenced dialog with a Citations tab, and change
		 the focus to this dragged item. (If no such Citation tab
		 exists, do nothing.)
         3.1.2  Event, insert the item as the last event in the last
		 referenced dialog with an Event tab, and change the focus
		 to the role field of this dragged item. (If no such Event
		 tab exists, do nothing.)
         3.1.3  Place, insert the item as the place field in the
		 last referenced dialog with a General tab, and change the
		 focus to this field. (If no such General tab exists, do nothing.)
         3.1.4  Text, insert the item as the description field in the
		 last referenced dialog with a General tab, and change the
		 focus to this field. (If no such General tab exists, do nothing.)
         3.1.5  Source, insert the item in the Source Citations tab of
		 the last reference dialog with a Source Citations tab, and
		 change the focus to this dragged item. (If no such Source
		 Citations tab exists, do nothing.)
         3.1.6  Repository, insert the item in the Repositories tab
		 of the last reference dialog with a Repositories tab, and
		 change the focus to this dragged item. (If no such
		 Repositories tab exists, do nothing.)
         3.1.7  Person or Family, do nothing.
     3.2  If the focus is not in a clipboard, copy the item to the last
	 referenced clipboard. (Do not change focus.)
 4  [Cntl-T] should change the focus within a window: 
     4.1  For dialogs with a top and bottom halves, it should toggle
	 the focus from top to bottom, or from bottom to top of dialogs.
	 The focus should be changed to be on the field that last had
	 focus, or if no such field, the first in the top half and the
	 last in the bottom half.
     4.2  For windows with a find field: if the focus is in the find
	 field, it should toggle the focus to the field (other than the
	 find field) that last had focus, or if no such field the first
	 one (other than the find field), and if the focus is not on the
	 find field it should toggle the focus to the find field.
     4.3  For windows with a side bar and/or bottom bar, it should cycle
	 around these and the display area, The focus should be changed to be
	 on the field that last had focus, or if no such field, the first field.
 5  The arrow keys should move focus within the relationship and chart views:
     5.1  The name of the person in focus should be highlighted.
     5.2  The focus should initially be on the active person or, if no
	 active person, the top person in the display area.
     5.3  [right-arrow] should move focus to the next person in the
	 display area.
     5.4  [Enter] should open the person dialog for the person in focus,
	 change the active person to this person, but not change the person
	 at the top of the display area, or any other part of the display area. 
     5.5  [Cntl-Enter] should open the person dialog for the person in
	 focus, change the active person to this person, and reconfigure
	 the display area with the active person at the top.
     5.6  [down-arrow] should move focus to the first person in the
	 next family.
     5.7  [left-arrow] and [up-arrow] should work similarly but backwards.
 6  If the focus is on a person (in relationship and chart views), or
 a citation (in an event editor) or an event (in a person editor), or
 any item in a clipboard, then [Cntl-up-arrow] and [Cntl-down-arrow]
 should move the items up or down, where possible.
 7  Accelerator [Alt+] Keystroke Assignments for each dialog should
 enable movement to each field with a single keystroke. (No omissions
 or duplicates.)
 8  The initial focus on opening the edit person dialog for existing
 persons should be the last event in the Personal section of the Event tab.
 9  [Alt-Q] should open the context menu with the focus on the first item.
 10  In the Person Dialog:	
     10.1  [Ins] should open a new event dialog for whichever of Birth,
	 Death and Burial does not already exist. If all exist, open a new
	 event with the focus on event type.
     10.2  [Alt-?] should open a new event of type Baptism, Christening,
	 Census, Occupation, or Residence where ? Is B, C, X, O or R.
     10.3  The focus (excluding the exception above) should be on the date.
 11  In the Family dialog, [Ins] should open a new event of type Marriage
 in the Events tab, with the focus on date.
 12  In the Events dialog, [Cntl-Enter] should save the event with
 the role Primary.
 13  In all of the select menus (Event, Place, Source, Citation,
 Repository, Media or Note), if there is precisely one item in the
 display area, [Enter] should select this item (even if the item is
 not in focus).
 14  [Cntl-Esc] should Close without Saving when this is an option.
 15  The keyboard shortcuts and accelerator assignments should be
 configurable by the user.
 16  A default set of keyboard shortcuts and accelerator assignments
 should be available based on Language.

This is a first stab at enabling building an existing tree, mouse free.
It does not include starting a new tree, correcting mistakes in a tree and producing reports.
I am not authorised to put this in the Roadmap Category of Discourse,
so have put it ideas instead.

David Lynch

[emyoulation]

Another option would be to extend the navigation functionality of the Go menus, bookmarks and clipboard into the Select menus.

Say that when Gramps launched, it populates each category’s Go menus with the 10 last modified Objects. Then add the ability to flip the Selector between the unfiltered records as it does currently but focused on the Active object and filtering (and ordering) on the Go, Bookmarks & Clipboard subsets. Like the other dialogs, it could remember the filter subset.

Also, the Select dialog could support the Ctrl - Ins keybinding to insert a New object after Browsing the existing objects. So users don’t have to duplicate the drill-down to add a new place, person or source in the hierarchy after verifying the object doesn’t already exist.

[SNoiraud]

I use gramps since 2006 on linux.
I don’t want the keybinding change.
If you want to do that, I think The default should not been changed.
We could have an extension (addon) for such a functionality.
Every gramps user could modify their keybindings.
We would have the choice for each operating system, then you can modify specific key bindings.

[comeng]

I agree with Serge key bindings are personal and ingrained, inherited
largely from whatever operating system somebody has spent the most time
on in the learning process.
The one that gets me every time
CTRL C & CTRL V obviously for me with a Windows background it catches me
when in Terminal it is SHIFT CTRL C or V.
A default set with a configuration option would be best.
phil

[emyoulation]

While documenting some navigation and keybindings in the wiki, I noticed a couple oddities.

The Jump keybinding (Ctrl+J) works if the main application window of Gramps was active… regardless of whether the last click was in a split bar (navigator, gramplet, toolbar, menu or title) or the center display area.

However, the Find (interactive search) keybinding (Ctrl+F) only works if the center display area is active. It would be a lot more useful it worked at the same times as the Jump.

The Go menu keybindings only use the numeric keys at the top of row, not the numeric keypad… even when in NumLock.

It is also odd that the Go history associations is sequenced.
It uses Alt+0 through Alt+9 when the top row of the keyboard is ordered Alt+1 through Alt+0.