Page MenuHome

Outliner: Keyboard navigation
Closed, ResolvedPublic

Description

In the Outliner, art should be possible to use the arrow keys to navigate the hierarchy:

Key Function
Up/Down arrowMoves the selection up or down by 1
Right ArrowOpen disclosure triangle
Left ArrowClose disclosure triangle
Hold ShiftExpand selection

Details

Differential Revisions
D4771: refactor: arrow keys navigation(walk_select)
Type
To Do

Event Timeline

A very nice!)
What about pickwalk behaviour in outliner?

@Paul Kotelevets (1D_Inc) By the very nature of this, of course you will be able to traverse the hierarchy.

Anything more complex is lower priority - initially users should be able to do the expected thing of simply navigating the hierarchy.

@Dalai Felinto (dfelinto) I think i could do it if you want, I have seen how it work on the space_file

@Valentin (Poulpator) If you would like to contribute a patch to do this, you are most welcome. I think @Dalai Felinto (dfelinto) has other high priority tasks to do in the meantime.

I realize this only aims for basic support. However for more than that I'd like to leave some notes here.

Keyboard navigation (aka walk-select) seems simple, but there are some non-obvious things to consider:

  • Assuming navigation is supposed to start from the last selected item, what is the last selected item for border select, select-all, etc.?
  • What if the last selected item got deselected again? Which one will navigation start from? Would we have to keep a selection history?
  • Usually either Shift or Ctrl causes items to be added to the selection, without deselecting previous items first.
  • When Shift/Ctrl-'walking into' a block of selected items (e.g. selecting item # 1, 2, 3, then from 3 navigating upwards towards 1), it's common to unselect rather than select. This should probably be supported too.
  • If so, what if there are selected and unselected items mixed (e.g. items 1 and 3 are selected, them from 3 navigating towards 1 - will the unselected item be selected or stay unselected?)?
  • What if the selection is out of view-bounds?

Navigation with hierarchy may be even more tricky.

As mentioned above, the file-browser has an implementation in which all these things were taken into account. The resulting logic isn't really straight forward though.

@Julian Eisel (Severin): Perhaps we could re-use the same logic from the File Browser? It seems a waste to have to re-create the same logic several times for this throughout Blender.

The main thing needed to make it work well is, just like in the File Browser, there needs to be one item which is the main active one, from which the keyboard navigation emanates from

Assuming navigation is supposed to start from the last selected item, what is the last selected item for border select, select-all, etc.?

Like the File Browser. The last item selected, where you released the box select.

What if the last selected item got deselected again? Which one will navigation start from? Would we have to keep a selection history?

This case is handles somewhat poorly in the File Browser. It just ignores that you deselected the last item and continues from there anyway. Could be better but is not a deal breaker to implement this IMO. It could also do something really simple, like start from the top-most selected item if the 'active' item is deselected.

Usually either Shift or Ctrl causes items to be added to the selection, without deselecting previous items first.

Yes, holding shift should extend the selection, just like in the File Browser.

If so, what if there are selected and unselected items mixed (e.g. items 1 and 3 are selected, them from 3 navigating towards 1 - will the unselected item be selected or stay unselected?)?

Holding Shift should always extend the selection I think. If you run over other selected items, they could just stay selected.

Other apps handle this in a simpler way: If arbitrary items are selected and you hold shift and start to walk the selection up or down, everything is deselected except for those items. I think that's fine too.

What if the selection is out of view-bounds?

Not sure what you mean. If the selected element is outside the view, I see no reason to handle this in a special way?

I realize this only aims for basic support. However for more than that I'd like to leave some notes here.

Not here, this is Shift related topic
https://developer.blender.org/T63989

A question -

Up/Down arrow Moves the selection up or down by 1

Moves selection or cursor frame?
UP/Down in most of commanders moves cursor,
UP/Down+Shift - making selection/deselection,
space - select/deselect current and move cursor down to next row

How is the idea about Ctrl + Shift + Up/Down to deselects one side and continue other side?

For example, these are the items:

Light
Empty Object
Sphere
Line
Plane

We start from first and navigating down up-to Shpere using Down Arrow.

Now Shift + Down Arrow also selects down (Line), again then (Plane).

If we want to selects also up, then Shift + Up Arrow to select Empty Object. But if your want to selects (appends selection) one side from active element. then i think in this case Ctrl + Shift +Up/Down Arrow could be used.

e.g. Ctrl +Shift + Up to deselects all down elements form active and starts add up items.

How is the idea about Ctrl + Shift + Up/Down to deselects one side and continue other side?

How is the idea, that this idea was already shown on GIF in previous post?)