Navigation via keyboard shortcuts changes depending on the selected area

Depending on where the user last clicked, the behavior of the Navigation shortcuts change. On the canvas, they usually work as expected, but once a state is clicked in the inspector or an element is selected in the tree, tab makes the name of the State/Element/interaction editable, while CMD+ up/down does not work anymore. If the tree is selected, the arrow keys can be used to navigate (up down), but I have yet to encounter a situation where this change in behavior is helpful. Usually I press tab and then another shortcut (like f for fill) and end up changing the name of the cell I selected, because tab made the name editable instead of navigating to the next cell. Please make these shortcuts work consistently.

Hi Vyse,

and welcome to our discussions :slight_smile: currently the navigate-shortcuts (Tab and ⌘↑↓) are handled only on the canvas, not in the other controls. Since tab normally advances to the next editable field, I guess it would be surprising if it will select the next cell (for example, you enter a new width in the style-inspector hit tab and have another cell selected). I think ⌘↑↓ could be made globally accessible without a problem.

For the behavior of tab edits the name: Here we use the standard behavior of the control from macOS, I guess the reason is that we did not define the next key view (that is the next editable field to select while hitting tab). But I have to try it out, this is just a guess.

But yes, the current behavior is not ideal.

Hi fifaz,

I wanted to ask, if there is any progress on this issue. What you describe in your reply sounds very much like what is required. I agree that the Tab feature should switch between values while inside a shortcut flyout, but other than that, there is little reason to not have it switch between cells I believe. The current behaviour is maddening when you try to work on a complex project and often have to select elements from the tree because it is hard to hit them with the mouse on the canvas. So you selevt an element and press “s” for size. The Size Flyout opens and I as a user am focused on the canvas again. After I finished editing the size, I want to jump to the next element by hitting Tab and instead the name in the tree becomes editable. (You could argue that this is partially my fault for nesting too many elements, but I doubt that applys for all cases in which this is a problem and it really costs time to manually select everything just because keyboard shortcuts don’t work as expected.)

Since i could not easily go through the elements individually, I tried selecting eight elements simultaneously to change their width. This resulted in a beachball of death that kept spinning for over 10 minutes now and it shows no sign of stopping. In fact it seems to demand everything from the Macbook Pro I am using, judging from how much the fans ramped up. Seriously: PLEASE fix this. This is not a minor issue to people who work with keyboard shortcuts (aka effectively).

So far I can’t tell you anything new regarding this topic, we will discuss this internally again.

1 Like

Well now we can tell you something new:
Update to the latest version and it will work :smiling_face:
(Antetype update: Native ARM support, new Cloud features and more)