[implemented] New shortcut key for cm_FocusButtonBarVertical

[petermad]

Just as the command cm_FocusButtonBar has the shortcut Alt+Shift+F11 I suggest to assign Alt+Shift+F12 to the new command cm_FocusButtonBarVertical

[Fla$her]

I don't understand people's mania for adding new hotkeys to default ones. Do you understand that because of this, the principle of preserving default hotkeys is broken for people who have had their own custom bindings of these keys for a long time? It would have been time long ago (a few years) to stop with the addition of new hotkeys. If there is an internal command, there is no problem with assigning a key on your own.

[Sir_SiLvA]

Just as the command cm_FocusButtonBar has the shortcut Alt+Shift+F11 I suggest to assign Alt+Shift+F12 to the new command cm_FocusButtonBarVertical

Support++

[Galizza]

Just as the command cm_FocusButtonBar has the shortcut Alt+Shift+F11 I suggest to assign Alt+Shift+F12 to the new command cm_FocusButtonBarVertical

Support+

[petermad]

the principle of preserving default hotkeys is broken for people who have had their own custom bindings of these keys for a long time

There is absolutely nothing that prevents you from continuing using your own custom binding in TC of Alt+Shift+F12 - user assigned TC-hotkeys has precedence over the default hotkeys.

[Fla$her]

There is absolutely nothing that prevents you from continuing using your own custom binding

How is it not, if it is noted right at the beginning of the quote — a violation of the principle of preservation (integrity)?
The priority for many is precisely not to resort to replacing hotkeys by default, including for the correct assessment of bugs and someone's actions.
This has nothing to do with the priority of reassigned hotkeys.
So, it's much easier for you to assign the specified hotkey to an internal command than for the author to implement a default binding to this command.
Therefore, before the release of version 11, we considered adding internal commands that are implemented in other ways (hotkeys, menus), and not vice versa.
There are too many internal commands to tie them all to something. We need to stop.

[petermad]

The priority for many is precisely not to resort to replacing hotkeys by default, including for the correct assessment of bugs and someone's actions.

This exactly speaks for having author-defined hotkeys, so we have a common interface to refer to.

[Fla$her]

This exactly speaks for having author-defined hotkeys, so we have a common interface to refer to.

And what does this change in relation to the glut of default hotkeys, which may be occupied by other functions?

[petermad]

And what does this change in relation to the glut of default hotkeys, which may be occupied by other functions?

Can you elaborate and perhaps exemplify this - to me your statement does not make sense. (do you perhaps mean "which may be occupying other functions" ? )

[Fla$her]

Can you elaborate and perhaps exemplify this - to me your statement does not make sense. (do you perhaps mean "which may be occupying other functions" ? )

It's all about the same thing. The keys can be occupied by other commands (I called them functions) specified by the user. Is this unclear to you or something else?

[petermad]

And as I wrote earlier - If a shortcut key combination is already used for anything else, via TC's shortcuts, then that shortcut will still work for the user as it used to, because users-defined shortcuts have prevalence over TC's build-in shortcuts - so I really don't see the problem - Build-in shortcuts (except for Alt+F4) are not occupying (preventing) the key-combination from being used for user-defined shortcuts to other em_commands than the original.

So the issue boils down to:
1. Should I and others who would like a shortcut - here Alt+Shift+F12 for cm_FocusButtonBarVertical - have to assign it ourselves.
or
2. Should Alt+Shift+F12 be assigned as a build-in shortcut, while the people who has already assigned Alt+Shift+F12 to something else, can just do nothing, and still continue to use that shortcut as before.

Voting for 1 gives extra work for people in that group, voting for 2 gives NO extra work for anyone (but the author).

[Fla$her]

And as I wrote earlier ...

I have clearly identified the problem, and you continue to repeat things that have nothing to do with it. What for?

So the issue boils down to:

No. Voting should be reduced to stopping or continuing to build up any default hotkeys (with the exception of dialog hotkeys, which cannot be reassigned). This is not a special case.

voting for 2 gives NO extra work for anyone (but the author).

This, frankly, is a very weak argument. And it relies more on beginners rather than experienced users, for whom this has never been a problem. Among all the potential settings, linking a hotkey to an internal command is an obvious trifle.

[petermad]

I have clearly identified the problem

No, you haven't yet managed to argue why build-in shortcuts should be a problem, as long as they can be overridden - you just state that it is a problem, referring to a self invented "principle of preserving default hotkeys" - whatever that is supposed to mean? Does it mean that default hotkeys should not be subject to be overridden.?

And it relies more on beginners

And what is wrong with accommodating beginners? That is exactly why I suggest it - it is certainly not for my own personal need.

[Fla$her]

No, you haven't yet managed to argue why build-in shortcuts should be a problem, as long as they can be overridden - you just state that it is a problem, referring to a self invented "principle of preserving default hotkeys" - whatever that is supposed to mean? Does it mean that default hotkeys should not be subject to be overridden.?

Where did I write that any built—in shortcuts are a problem? I wrote that adopting new combinations is a problem. These are not equivalent things.
Many people are used to the old combinations, just as they are used to their own. But suddenly on these "own" it is proposed to bind something else by default.
There is no self-invented principle. It didn't arise spontaneously in my head. It has existed in the community for quite a long time.
Every now and then we come across when someone gives the wrong hint with a custom keyboard shortcut. More experienced colleagues suggest that by default this combination performs a different action. This experience is based on the predictability and consistency of mastering the built-in list of combinations. By adding new combinations, users lose the desire to comply with this organized and holistic principle, which in general is harmful to the community.

And what is wrong with accommodating beginners? That is exactly why I suggest it - it is certainly not for my own personal need.

It's good that you confirmed it. I don't think it's right to cater in such a controversial way to any potential pool of beginners, given the huge current user base that will face this contradictory situation.
But why did you give a link where the request was for a command and not a hotkey?

[petermad]

Where did I write that any built—in shortcuts are a problem?

And where did I write that you wrote it?

Every now and then we come across when someone gives the wrong hint with a custom keyboard shortcut.

And you think that this will accelerate if more default shortcuts are applied? - I don't.

With more than 115 default shortcuts, I think we are past that. In fact one of the most common keyboard remappings that people refer to here in the forum is the F2 remapping to inline renaming - and F2 has been the default shortcut for reread the file panel since TC was born and only had 40 shortcuts.


So I don't think restricting the number of default shortcuts is the solution to the problem with users referring to their own custom shortcuts, as if they were the default.

What could help on that situation would be if TC would warn about overriding default shortcuts, when making a user defined shortcut, so the user would know that he is about to override a default shortcut.

But even that would not eliminate wrong referring to shortcuts, because people simply forget that they have remapped a shortcut after a while.

But let's just agree to disagree on this matter.