Total Commander

The unified command system I suggested years had been a fully-fledged approach to unify all the ways command can be initiated in TC. Many things have changed since then. There are now universal actions which can be used in many places.
However I think there is room for improvement without reinventing the wheel.

Consistent editing of buttons, menu items, hotkeys, …
Editing the button bar, menu bar (and other places where actions can be launched) is currently very different. In case of the menu it’s really cumbersome. It requires manual editing of the menu file and former creation of em commands.

Transparent creation of actions
When creating a button the command is directly created in the button. When I want to assign a hotkey to it or add a menu item I have to create a command first.
So the idea is to always create a command when creating a button. This should be done everywhere were it makes sense.

Users in a very long German thread asked how to create submenus in the buttonbar. Other asked how it could be improved. Well this is the reason for this thread. So I took some time and tried to create a visualization that is really easy to understand.

Let's start with the current situation. There are so many ways to edit all these very similar structures:
http://lefteous.totalcmd.net/tc/ideas/existing_editing_solutions.png

Here are two examples on how it could work. One is for the main menu and the other one explains how a submenu and an item in this menu could be added bases on 'unified' solution idea.
http://lefteous.totalcmd.net/tc/ideas/edit_structure.png

Combined editing of nested buttonbars looks nice. But I don't think that two fields for buttonbar file (existing/new) paths required, one should be enough. And button parameters like 'show as menu' should be displayed anyway (now one can easilly convert any regular button to menu or back and change icon), and such options (icon, tooltip) should be simply common for any button type so they may be shown separately.
I don't think it is a good idea to always create a command when user adds a button to buttonbar. It will be a huge mess of commands when user has hundreds of buttonbars, and such buttonbars will not work without proper usercmd.ini.

2MVV
Thank you for your feedback!

Combined editing of nested buttonbars looks nice.

What exactly do you mean by 'combined'?

But I don't think that two fields for buttonbar file (existing/new) paths required, one should be enough.

This is something that isn't different from the current implementation. When designing my suggestion I paid attention to not use constructions that could break compatibility. Maybe I didn't understand what you ment?

And button parameters like 'show as menu' should be displayed anyway (now one can easilly convert any regular button to menu or back and change icon), and such options (icon, tooltip) should be simply common for any button type so they may be shown separately.

I think the current 'convert any button type to any other button type' solution is to complicated. I tried to find a compromise when adding the dropdown in the upper right hand corner for existing/command button type. I will try to do something similar for the submenu/switch buttonbar button type and also add a regular command for switch buttonbar command - good hint!

I don't think it is a good idea to always create a command when user adds a button to buttonbar. It will be a huge mess of commands when user has hundreds of buttonbars, and such buttonbars will not work without proper usercmd.ini.

I don't think it would be an issue. In the end you have less commands as you avoid duplicates. Creating em commands would be really something that comes for free. In addition you have a nice list containing all user-defined commands.
If you really don't like it there is a checkbox. But you will regret it the day where you want to create a hotkey or a menu item...


I have updated the mockup to reflect your feedback.
http://lefteous.totalcmd.net/tc/ideas/edit_structure.png

What exactly do you mean by 'combined'?

I mean tree view with nested bar buttons.

This is something that isn't different from the current implementation. When designing my suggestion I paid attention to not use constructions that could break compatibility. Maybe I didn't understand what you ment?

Currenty you can open or create buttonbar file using same browse dialog (if you type non-existing file name, it will be created). Your mockup shows separate fields and browse buttons for existing and new buttonbar files.

But you will regret it the day where you want to create a hotkey or a menu item...

Perhaps 'Convert to em-command' feature of buttonbar editor (that creates em-command and points current button to it) could be more useful here.

2MVV

Currenty you can open or create buttonbar file using same browse dialog (if you type non-existing file name, it will be created). Your mockup shows separate fields and browse buttons for existing and new buttonbar files.

Although I think it's strange to use the open dialog for non-existing files both ways are okay. It's not a central element of the design.
One way to improve the 'load existing' part could be to provide a list of known buttonbars in a dropdown - like a recent list.

Perhaps 'Convert to em-command' feature of buttonbar editor (that creates em-command and points current button to it) could be more useful here.

When editing an existing command the checkbox wouldn't be checked. The user could check it manually which is literally the same as the button you suggested. Using the checkbox instead of the button implies an em command is created by default when creating a new button.
Maybe there could be some trigger to set the checkbox but I'm not so sure sure about this.