Outliner: Keyboard navigation #63992

New Issue

William Reynish · 2019-04-29T16:57:10+02:00

William Reynish commented

2019-04-29 16:57:10 +02:00

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

Key	Function
Up/Down arrow	Moves the selection up or down by 1
Right Arrow	Open disclosure triangle
Left Arrow	Close disclosure triangle
Hold Shift	Expand selection

William Reynish commented

2019-04-29 16:57:10 +02:00

Added subscriber: @WilliamReynish

Dalai Felinto was assigned by William Reynish

2019-04-29 16:57:23 +02:00

Paul Kotelevets commented

2019-04-29 20:28:05 +02:00

Added subscriber: @1D_Inc

Paul Kotelevets commented

2019-04-29 20:28:05 +02:00

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

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

William Reynish commented

2019-04-29 20:36:04 +02:00

@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.

@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.

Valentin commented

2019-04-29 21:03:56 +02:00

Added subscriber: @Poulpator

Valentin commented

2019-04-29 21:03:56 +02:00

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

William Reynish commented

2019-04-29 21:11:19 +02:00

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

Julian Eisel commented

2019-04-29 21:53:39 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2019-04-29 21:53:39 +02:00

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 {nav Shift} or {nav Ctrl} causes items to be added to the selection, without deselecting previous items first.
When {nav Shift}/{nav 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.

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 {nav Shift} or {nav Ctrl} causes items to be added to the selection, without deselecting previous items first. * When {nav Shift}/{nav 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.

William Reynish commented

2019-04-29 22:26:23 +02:00

@JulianEisel: 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?

@JulianEisel: 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?

Paul Kotelevets commented

2019-04-29 22:53:11 +02:00

In #63992#668134, @JulianEisel wrote:
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

> In #63992#668134, @JulianEisel wrote: > 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 ![Double commander dir.gif](https://archive.blender.org/developer/F6993005/Double_commander_dir.gif)

Abid Maqbool commented

2019-05-17 06:39:17 +02:00

Added subscriber: @AbidMaqbool

Abid Maqbool commented

2019-05-17 06:51:42 +02:00

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? 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.

Paul Kotelevets commented

2019-05-17 21:31:31 +02:00

In #63992#681182, @AbidMaqbool wrote:
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?)

> In #63992#681182, @AbidMaqbool wrote: > 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?)

Nathan Craddock commented

2019-08-17 00:20:16 +02:00

Added subscribers: @dfelinto, @natecraddock

Dalai Felinto was unassigned by Nathan Craddock

2019-08-17 00:20:16 +02:00

Nathan Craddock self-assigned this 2019-08-17 00:20:16 +02:00

Nathan Craddock commented

2019-08-17 00:20:16 +02:00

Changed status from 'Open' to: 'Resolved'

Nathan Craddock closed this issue

2019-08-17 00:20:16 +02:00

Nathan Craddock commented

2019-08-17 00:20:16 +02:00

Walk navigation is added in 252fb48997

Walk navigation is added in 252fb4899735

Paul Kotelevets commented

2019-11-16 18:09:19 +01:00

In #63992#754738, @Zachman wrote:
Walk navigation is added in 252fb48997

What kind of walk navigation?

> In #63992#754738, @Zachman wrote: > Walk navigation is added in 252fb4899735 What kind of walk navigation?

Nathan Craddock commented

2019-11-17 02:15:12 +01:00

In #63992#812139, @1D_Inc wrote:
What kind of walk navigation?

Exactly as described in the description of the task. Arrow keys up and down and left/right arrows to open close a level. :)

> In #63992#812139, @1D_Inc wrote: > What kind of walk navigation? Exactly as described in the description of the task. Arrow keys up and down and left/right arrows to open close a level. :)

Paul Kotelevets commented

2019-11-17 14:36:14 +01:00

In #63992#812222, @Zachman wrote:
Exactly as described in the description of the task. Arrow keys up and down and left/right arrows to open close a level. :)

Aw, ok, thanks for explanation)
There were discussions about "pickwalk" navigation abilities - expanding the selection according to the structural tree of collections, like in S-UP addon concept we made some time ago, got a bit confused about terminology :)
Sorry)

> In #63992#812222, @Zachman wrote: > Exactly as described in the description of the task. Arrow keys up and down and left/right arrows to open close a level. :) Aw, ok, thanks for explanation) There were discussions about "pickwalk" navigation abilities - expanding the selection according to the structural tree of collections, like in [S-UP addon ](https://github.com/Korchy/blender_s_up) concept we made some time ago, got a bit confused about terminology :) Sorry)

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Outliner: Keyboard navigation #63992