Focus does not always work in right sidebar

#1

Linux
Nightly Build: 9.2.613

Something that I have been confused about for a while is “focus” in the right sidebar. Sometimes keyboard keys such as arrow keys work and sometimes they do not.

EXAMPLE
-Open a session with many tracks
-Open up right sidebar in the Editor
-In drop down have this sidebar show Tracks section
-Click on a track in the Tracks list to apply focus
-Now try to use your arrow keys UP / DOWN to move cursor
-Sometimes this works for me and other times you can see the Editor pane moving up and down instead.
(Which is another instance of something I have mentioned in the past, where many dialogs/windows that you think should have focus, do not, they only get part focus and random key presses cause actions to happen to your session in the background.
Hopefully things like this will get addressed someday)

Anyways, as I have mentioned, the ARROW keys do work on occasion.
When they do work, my ENTER key also performed a rename action which is nice.
So it appears to be possible.

QUESTION 1
I was wondering if anyone could confirm if this is a bug, or if I am not understanding what gives focus to this right sidebar?
If so, please share with me how to apply focus to the right sidebar.

QUESTION 2
I also made a suggestion post in the past, to allow focus to the Clips section. This would allow user to be able to move the cursor up/down to activate “Preview” of audio files using your PC keyboard, instead of having to left mouse click on each audio file manually one at a time which makes the “Preview” feature not that useful.
Is this already possible? and maybe I am experiencing the same focus issue I mentioned above?
Or is this not possible at all in Clips section?

Thank you to anyone who reads this and for any info shared

#2

Still interested if anyone has any information to share.
Thank You

#3

Concerning Question 1:

It is not a bug, and it happens to me too. The only difference you’re experiencing (most likely) is where your mouse hovers once you click something. -I.E., if you click a track in the Right Panel and then immediately, even slightly move your mouse to the left so it’s hovering over the editor, then up/down arrows will move the editor up and down, route-by-route. But, if you click and keep your mouse in the Right Panel, up/down arrows will move your track/bus selection up and down, route-by-route (and you can hit enter to change the name, etc.):

Ardour 9 - Mouse Hover Takes Precedence Over Clicking, Unfortunately

This indeed is annoying, and imo should NOT depend on where the mouse is hovering, but where one last clicked.

I myself have raised a similar case in this report: 0010197: Mixer strip fader dB field automatically deselected when your mouse leaves the strip - MantisBT

Hopefully understandably, oftentimes when you click something, there’s an immediate, somewhat habitual next motion of the mouse, in this case to get the mouse out of my way so I can see what I’m about to type:

Ardour 9 - Fader dB Field Automatically Deselected

However, again, when you do that, an automatic de-selection occurs. :pensive:
(FYI: I’m more-or-less used to it by now. But in the beginning, little things like this just felt ‘off’ to me.)

So, in summary, yes, I agree with you here, and I’ll repeat the request:
Interaction with Ardour should NOT necessarily depend on where the mouse is currently hovering. -Clicking/explicit-selection should always take precedence.

Concerning Question 2:

I don’t use the “Clips” section at all, so I have no input on the matter. : P

Cheers!
-J

#4

We use a mixture of focus-follows-mouse and click-to-focus in Ardour. When it comes to the main editing canvas, if your mouse enters it, we consider keyboard focus to be transferred there, and keyboard events will activate editing shortcuts.

This is a fairly deep assumption in our UI design, driven partly by the fact that both @x42 and I are focus-follows-mouse people. Click-to-focus (common on macOS) is generally rather cumbersome to use unless your UI is full of things that you only click (i.e. few or no kbd-shortcuts). We do use click-to-focus on some specific widgets (e.g clocks, text entry fields).

#5

That being said, the sidebar does not take focus back when moving the mouse over it once it has lost it to the editor.

#6

Right, lists and so forth are click-to-focus, because … that’s just how they are, mostly.

#7

Interesting thread. I’ve also noticed this occasionally and wondered what the explanation was. I guess an obvious answer would be to have a preference setting (click-to-focus or focus-follows-mouse)? but presumably that’d have unwanted consequences?

1 Like
#8

QUESTION 1 RESPONSES
(Unfortunately I typed this before reading a recently upsetting post)
Wow, thank you guys for all of these responses.
I must say although this post is not going to necessarily change anything, I agree, this did turn out to be an interesting thread.
Overall the responses all pertain very well to the topic.
You guys even mentioned some of nuance behaviors that I would have mentioned as well.
In a specific way this might be one of my most favorite posts as far as responses.
Thank you guys again

@jean-emmanuel
Hello again, recognized your name.
Also, I already thanked you in those posts, but thank you again for working on so many of my bug/suggestion posts, I really appreciate you taking the time to make those updates.

#9

@paul
@any other developers / users interested in fixing/testing this out

QUESTION 1
Okay, so now at least the current behavior has been explained so I have an idea of what to look for.
I have been able to generate the described behavior of how to apply focus, but at times I still experience the random issues I had mentioned.
I think the reason for this still occurring is that there is some kind of a bug present.

Took a lot of time and testing to figure this out.
…and I think I found it (or at least one of the reasons)
https://tracker.ardour.org/view.php?id=10362
This issue is also linked to another issue I mentioned in this link as well.

If anyone is willing to confirm/fix

#10

QUESTION 2
Edit - Sidebar - Clips
I have never been able to apply focus into this section.
I believe that is because this specific section does not allow keyboard based focus at all.
I think this section in general may need a little attention.

Clips Drop Down At The Top Of Section
There are some issues with this drop down.
I have a Mantis post about one of them already that was half fixed but has now generated 2 issues that I have to create new posts for.
There are also a couple more possible issues I noticed with this drop down that I will have to create posts for as well.
If anyone wants to keep an eye out for these posts.

Clips List Pane Focus
Again, does not allow focus at all currently.
I have a general feature request post about allow keyboard focus in the sidebar.
Now that I know that it is possible, I will probably close that post and create a new feature request post based specifically about the Edit-Sidebar-Clips section.

I was wondering if developers / users would agree that this section then should also get the same behavior added to it, where LMB click inside Clips section applies keyboard based focus/navigation (such as UP/DOWN ARROW keys).

I think this section would greatly benefit from this keyboard based focus/navigation.
Currently this section only allows for mouse based interaction, requiring LMB clicks on each clip (audio sample) to “preview” them, which is not that efficient/comfortable to have to keep clicking on each of them.
Keyboard based focus/navigation would allow user to be able to use ARROW UP/DOWN keys to “preview” clips (audio samples) much more efficiently.

As mentioned in the past, I try to focus my tests/suggestions based on minor possible workflow improvements/minor bugs that I experience/come across, such as the items mentioned above.
I know that most focus has to go into music production based updates (which you guys are doing excellent work on) but hopefully some of my many posts can be considered from time to time as well.
I know they might seem “minor” but I think that these little workflow suggestion/GUI updates/minor bugs/etc. can add up to be beneficial to some users.

Not really sure what to do, I come across items quite often.
I try to make as many posts as I can when I notice/experience anything but it is hard to know what items would be considered to be updated/worth spending so much time and effect testing and typing posts for?

In this case, Ardour sidebar sections offer users so many great features/information about sessions, I would imagine many users make use of it.
So I think these updates could be worth making.
Hopefully these fixes/updates will be considered to be added.

Thank you to anyone who reads this