Is there any interest in adding Top \ Bottom options to the embedded list class?
Something like this mock-up. I think these would be relevant for all lists that have move buttons.
I’d also be interested to have a way to move an existing event to the correct location based on Date. When a new event is created it is added to the bottom of the list. I like to keep my events in date order, so I have to manually move to the correct location. With a long list of events this becomes time consuming. This proposed command would adjust the events position such that all events above it in the list have an earlier or equal date. Something like this mock-up
This is a bit more specific and may only be relevant to event lists.
I’d rather see a modifier key added to the existing button rather than the clutter of another button. Such as the Ctrl button amplifying the ∧Up/ ∨Down buttons to a Top/Bottom
There is already a Date sort by clicking on the Titlebar for that column.
The problem is that the Interface does not allow that sorted order to be pushed into the indexing for that table.
However, there is ONE column that DOES do that… although with a overly complicated and inconsistent workflow.
If you sort on the Description Column then click the Type Header, clicking the Up/Down releases the Sorting indicator but leaves that re-ordering in place. (Additional Up/Down can be applied. The new order is only saved if you click the OK button.
But that behavior only works SOME of the time. Other times the re-sort asserts itself.
How about if the the behavior was uniformly codified?
If no header has a Sorting Column indicator, then clicking a column header sets that as the Sorting Column in ▼ascending order. Click again sets to ▲descending order.
If you click on anywhere else in the table, the sort direction Indicator is released and that becomes the temporary “native” Sort order … but all the other controls (drag’n’drop, ∧, ∨) could become unlocked again.
There is only thing that doesn’t seem to have a good fit – restoring the default index order. The index column is hidden, so you cannot use the header sorting. Using the Cancel button would also discard any other changes made since the dialog was spawned… added/removed secondary objects, name edits, tagging or privacy changes, et cetera.
There’s a real need for expanding and collapsing lists using the keyboard, and jumping to the start or end of the list (Gramps already lets us go up and down one item at a time). We could get into details of which keys do what and such in a dedicated thread or GEP, but I would totally support keyboard shortcuts for navigating lists.
Well, at least in Fedora, the List (table) views support the Home and End keys for top and bottom of the list. And while the Up and Down cursor keys move the focus one row at a time, the Page Up and Page Down keys move the focus a screen at a time. (Shift expands the selection in addition to moving the focus. Shift-left-click or center scrollwheel button on the scrollbar will snap the scrollbar button to the click. Right-click does a slow scroll. And there’s vertical scrolling with the scrollwheel or horizontal with shift-scrollwheel. )
So you’d expect the Tabs in the Object Editors to follow the same keystrokes. It would just need new keybindings to toggle between the Top panel and the Bottom panel.
Likewise on Windows the following work (on the Person editor event list)
Up \ Down arrows = move selection Up \ Down 1 item
Page Up \ Page Down = move selection down one page (page size is determined by number of visible rows)
Home - move selection to top of list
End - move selection to end of list
Shift does not do anything on Windows. Shift + Up arrow just moves the selection up one item. Only one item is actively selected.
Ctrl + Up arrow moves the focus to the item above, but leaves the original item selected.
Does multiple selection work on Linux and can you then move multiple items Up \ Down? That would be useful as well.
Can you only select a single continuous group of items or can you select say the first, third and fifth items.
It’s the indexing I want to set, not the current visualisation.
I actually want to sort of Date and then a secondary criteria of Type. I like to keep the source event e.g. Census, immediately above the events created from it e.g. Occupation. But that’s just my convention and so therefore not something to add in the core software.
What I didn’t explain clearly enough is the need to expand/collapse a group when the focus is on an item in the list. So if you’re in the Grouped People view, say at a person in the G > Garner in the Gramps example tree, using the keyboard there isn’t a way to collapse the Garner group so you can easily go up to Gardner, or down to Garrett.
Gramps is actually halfway there - if the group header is selected, e.g. “Garner” you can use Shift+Left Arrow to collapse, and Shift+Right Arrow to expand. It would be super helpful to add that same capability to each item in the group. Hope this clarifies my wish better.
Grouped view is missing one thing from my perspective
Selector Buttons A to Z running along the bottom of the view to allow jumping to the start of the appropriate surname group rather than scrolling up and down.
I do not have a particularly large tree 2500 surnames but it is a pain scrolling through.
phil
Remembered why Shift&A etc was on my do not use list
It goes to the first Surname beginning A and then opens that group which seems to hang the program for a few seconds and then you need to close the group especially if it is large and not the one you want. To make it useful it should just jump to the first surname beginning A with all groups unexpanded then you can scroll to the group you really want.
phil
There’s another oddity (although less obvious when using ‘A’ as an example)… if there’s a ‘Z’ surname Grouped in another surname, Shift&Z jumps to the ‘Z’ in the other surname.
Another if you have “de” as a prefix then Shift+D brings up the surname
prefixed by “de” so in this instance de Cogan which should come up under
Cogan the Group Name.
Thus the function is looking through all the surnames and not just the
Group names hence the momentary delay.
“van” prefix does the same.
phil
The “shift” is irrelevant for the Interactive Find feature.
Ahhh. Then for that interactive Find, Gramps must be creating a “Display As” formatted list in the “Grouped as” order.
Need to do a test to see if the list uses the override or the default “Display as” for the preferred name. And if the override affects the order in the sub-groupings. (I have rarely used that override.)
The Grouped Person is the most complex functionality. By default, it is sorted on the Grouping name then sub-sorted on the ‘Name’ column in the ‘Display As’ Name format from the Data menu of Preferences. That will be the Preferred/Primary name in “Surname, Given Suffix” format and the “Surname” includes the Prefix and Connectors. However, the ‘Group as’, ‘Sort as’, and ‘Display as’ settings can be used to override the order using the ‘Name Editor.’ So you can override those “de” and “van” prefixes with the Name Editor controls.
