Underline Shortcuts for Toolbar Tabs
AbandonedPublic

Authored by Aaron Carlisle (Blendify) on Sep 4 2015, 1:35 PM.

Details

Summary

With this patch, toolbar tabs can be switched by pressing the underlined character of the tab on the keyboard while hovering over the toolbar.
K, D, I, E get avoided when assigning shortcuts. The screenshot is outdated.


The character to underline in a certain tab is currently automatically found. Another way to do this would be to scan for an ampersand in the toolbar category name. This however would introduce conflicts with multiple addons defining names with the same character as a shortcut.

Diff Detail

Repository
rB Blender

Quick & direct access to tabs is good to have so am not against this ability in principle.

The main downside to this is we have some key bindings for buttons,

  • I, insert keyframe.
  • D, insert driver
  • K, keying set
  • E, eyedropper

While this panel is currently used *mostly* for tools (not properties), we may end up using tabs elsewhere too.

Its possible to only switch tabs if the mouse isn't already hovering over a button... but this is weak/error prone IMHO.

Also worth noting, Ctrl+Wheel already switches tabs.

Having the same concerns as Campbell mentioned. Nice to have, but corner-cases might make it a bit weak to work with.

@Jonathan Williamson (carter2422), @Pablo Vazquez (venomgfx), @Paweł Łyczkowski (plyczkowski) what do you think?

Hmmm... Maybe some modifiers(ctrl, ...) would make this possible?
I even initially started the implementation with having to hover over the tabs while pressing the key before I started checking the keybindings and missed the mentioned ones...
It could also work around those keys when assigning, but that might be a little more complicated/expensive when users have custom keymaps... (It would have to scan over all the shortcuts, took a quick look, seems possible). Just an idea.

While modifier keys are always a quick solution, it's in most cases not a really good one: Operations hidden behind a modifier key are hard to discover and it limits our freedom for future shortcut huntings.
We're running out of shortcuts everywhere already - we need to be careful with adding new ones.

I think ignoring the mentioned keys when assigning is a better approach. They are currently hardcoded (see ui_do_button, interface_handlers.c), so we don't need to do any expensive keymap lookups currently.
We could even use defines for these hardcoded shortcuts:

#define UI_EVENT_EYEDROPPER    EKEY
#define UI_EVENT_KEYFRAME_INS  IKEY
...

Ignoring keys we use means that if we add new keybindings to buttons. Users loose their panel shortcuts.

We could use numbers as an alternative, though you wouldnt get the underline reference.


Am not sure its so useful to use key bindings here. If you use the tool-bar, you're already using the mouse, So you can either click on the tab, or mouse-wheel cycle them.

most software things like this are use ALT+ Whatever character might think about using that

Marcelo Mutzbauer (1xundoredo) updated this object.
  • Skip hardcoded keys when assigning shortcuts

However, this is not a solution. What if the user saves with S instead of Ctrl+S? Will upload number-based approach in a comment.

This is the patch which is based on numbers. I am not updating this diff because this might be unrelated. Or should I change the title?

This is how the work flow should work in my mind. When the mouse is in the tool bar and the user presses alt the underlines show up and then the user hits the character for the respected tab

@Aaron Carlisle (Blendify) While that might be possible(by working around shortcuts like Alt-A) similar problems to the one mentioned by @Campbell Barton (campbellbarton) occur when adding new shortcuts with the Alt key(Tab shortcuts would change). Hiding the underlines until the user hits Alt might help not having to scan the keymap on every redraw, it also makes it harder to discover the feature.
The problem I found with Ctrl-scrolling(maybe that's just me) is that it is easy to miss the tab of interest when working at a certain speed. It is at least harder than just hitting a key. Also, the direction and number of times to scroll changes depending on what tab you're in. Shortcuts remain the same and over time you might memorize them.
I don't even think number shortcuts are a bad solution. There are two issues with them, though: 1. The number icons take up space 2. We run out of numbers when we have more than 10 tabs(Like in the screenshot I attached in my prev comment).
The 2. problem could be solved by having to type multiple 'digits'. This is a patch which tries to do that. The way it counts is 0,1,2,3,4,5,6,7,8,9,0,11,22,33,44,...99,00,(Now it starts counting regularly and skips all the number it already has used)10,12,13,14,15,...21,23.... I thought two same numbers are a bit quicker to type. But this might also be a little bit confusing. A Screenshot is attached.

I'm with @Campbell Barton (campbellbarton) and @Julian Eisel (Severin) on this one. In theory this is a good thing to support, particularly since we do so with menu entries already, but I think it's too tight of a corner case that causes more problems than it solves. As @Campbell Barton (campbellbarton) mentioned, we already have CTRL+Wheel to change tabs and I don't think we should be adding yet another way to change tabs.

@Marcelo Mutzbauer (1xundoredo), thanks for the patch nevertheless. I still think it would be useful, but sometimes such unpleasant decisions need to be made. Hope you're not disappointed :)

@Julian Eisel (Severin) No worries! :)
@Aaron Carlisle (Blendify) How did you do that? Just curious . . . Thx btw

@Marcelo Mutzbauer (1xundoredo) first make sure you are the commander of the differential and under the action drop down menu in the add comment section select abandon