[TC 8.0ß6] Unable to save shortcut in some cases

[petermad]

2Flint

TC implements the approach with explicit OK instead of immediate applying the changes. You wish to break all this and switch into the OK-less method? Fine, but why only in hotkey configuration? Why each and every other dialog continues to need the OK button

It is not correct that it would be the only option where pressing OK in a sub-dialog saves settings permanently, and does not need an OK in the Main config dialog.

These places listed below are also saved immediately and don't need OK in Main config (and Cancel i Main dialog does not cancel the choice made in in the sub-dialog):

Color -> Define colors by file type
Custom columns -> New / Edit
Edit/View -> Configure Internal viewer / Associations
Plugins -> All the Configure options
Packer -> Configure packer extension WCXs

Actually wherever TC uses a sub-dialog for configuration, an OK in the sub-dialog saves the setting, without having to press OK in the Main config dialog - all except the Choose command dialog - so actually this is the inconsistent setting.

You might argue that input are also made in the Main config dialog when remapping keys, so that should call for an OK in the same dialog, but choosing what key to remap isn't that different from for example choosing a Custom column to edit.

But - we can't get rid of the green checkmark anyway - it is necessary for defining more than one Alias at the same time, since no sub-dialog with it's own OK button is involdved for defining Alias'es.

[Flint]

Actually wherever TC uses a sub-dialog for configuration, an OK in the sub-dialog saves the setting, without having to press OK in the Main config dialog - all except the Choose command dialog - so actually this is the inconsistent setting.

Sorry, you did not convince me. Almost all the dialogs you mentioned (with one exception, details go below) do exactly what they are supposed to do.

1) Define colors by file type: For instance, you define a file type color, then press OK in color selection dialog and thus confirm your choice of the color. No more, no less. Now you see the new type with the color you selected — but the new coloring entry itself is not saved until you press OK in another dialog, the one controlling the colorizing file types themselves.
Summary: In the "Choose color" dialog you're choosing the color, so when you press OK the color is chosen. In the "Define colors by file type" dialog you edit the set of coloring rules, so when you press OK there the set of rules is saved.

2) Custom columns: You press New/Edit thus opening a dialog for editing the specific set of columns. So when you press OK you confirm what you edited — which is the columns set, and therefore it's saved.

…

n) Configure hotkeys: You open "Choose command" dialog, press OK — this confirms your choosing of the command, again, no more, no less. The command is chosen now, but what for? Hotkey, buttobar element, EM-command, Start menu? Whatever it is, it's controlled by the underlying dialog, the one from which you called the "Choose command" dialog. Now it shows you the selected command — because you confirmed your choice of the command — but you did not yet confirm the binding of this command to whatever you are trying to edit. This confirmation is performed by pressing OK in the corresponding dialog, or (in case of hotkeys/aliases) by pressing a dedicated button with green checkmark.

So, as I see it, everything goes in accordance to the same, common UI concept.

The only exception from this rule is the "Configure WCX Plugins" dialog (and "File Associations" dialog as well, since they are actually the same): when you select an extension and modify a path of the plugin/program, then change the extension, TC asks whether you should save your change. That's against the rule I described above (and I find this a very poor design, by the way), but at least TC warns the user explicitly and suggests to save the change, so the modification will neither be lost, nor overlooked.

Theoretically, TC could do the same with hotkey configuration: you select a hotkey, then a command, then specify new hotkey — and TC would ask whether you wish to save or discard the previous hotkey assignment. Well, it would eliminate all my objections about possible problems and unintuitiveness of the interface, but such design looks just terrible to me. (I start to specify a new hotkey — suddenly a question appears, I have to switch my mind to the question, read&understand it, remember about the previous hotkey, make a desision, then switch my mind back to what I was going to do now, continue specifying the hotkey… It's bad with file extensions, and it would be bad with hotkeys.)

Another example of how this could be implemented without bothering my sense of beauty is opening a separate, dedicated dialog for defining the whole hotkey. Just like custom columns, for example. So that there is some list of all redefined hotkeys, you press New — a dialog is opened where you enter the hotkey itself, the command (which is selected by pressing OK in "Choose command"), and then press OK in this imaginary dialog to confirm your hotkey assignment, which is saved immediately. This solution would be completely in accordance to the rules — but unfortunately less efficient than the current solution and quite uncomfortable for users because of many excessive dialogs and mouse clicks.

[petermad]

The command is chosen now, but what for? Hotkey, buttobar element, EM-command, Start menu? Whatever it is, it's controlled by the underlying dialog, the one from which you called the "Choose command" dialog.

Excactly - TC knows whwn the"Choose command" dialog is opened for what reason it is opened.

I still think the Custom column configuration is the one that is closest to the keyboard remaping: You pick a custom column, you click Edit, you edit the Custom column you picked and press OK to save the changes, and do not have to confirm once more in the Main config dialog that it was actually this Custom column you wanted to edit.

Same thing with Keyboard remapping: You pick a key combination to remap (notice you cannot open the Choose Command dialog until you have picked a key) - you edit which command you want for the key and press OK (to save the change in my implementation), and do not have to confirm once more in the Main config dialog that it was actually this Key combination you wanted to edit (my implementation).

Where is the difference? - except from one being a list and the other a list that can be combined with 4 modifiers.

[Flint]

Where is the difference? - except from one being a list and the other a list that can be combined with 4 modifiers.

The difference is: when editing a custom columns set you open a specific dialog exactly for that purpose, and when editing a hotkey you open a dialog not for editing a hotkey but for choosing a command only. To me your suggestion looks, as if when editing custom columns you needed to open a separate dialog to select a plugin field (instead of drop-down menu), and when you pressed OK in that dialog the whole your columns set was immediately saved, before you even press OK in the "Custom Columns" dialog.