Unified Command system
There is currently no unified system to manage commands in Total Commander. Commands are internal commands (cm_*) and user-defined commands. The current system works but it's quite difficult to handle. A redesign should be made. The following list compares the current and a possible new system.
The current system - Disadvantages of the current system:
- User defined hotkeys depend on on start menu items. Changing the start menu item order will make hotkeys work improper or even call the wrong command! In addition you sometimes want to assign a hotkey to a command but actually don't need the menu item.
- There is a hierarchy between menu hotkeys and user defined hotkeys.
- Hotkeys in menus are not updated automatically. You have to do this manually.
- Checkbox states in menus seems not to be part of an embedded system which enables automatic updating. This often leeds to missing states in menu items.
- Check states for buttons are completely missing.
- No separation between structure and language dependant information. This leads to redundancies and many other problems. Example: Exchanging of menu files doesn’t work very well. They contain language dependant captions and hotkeys.
- The function key bar always shows the default commands for the functions keys. Reassignments are not handled.
Benefits of a unified command system
- A single point of access (the command manager) is presented to the user.
- Commands are control independent. A command can be assigned to as many control as the user wants.
- Implementing a system based on the observer pattern will solve the updating problem for all checkboxes, captions and all other properties in all controls.
- Exchanging of user defined menus would be possible without or with much less translation.
New vs. old system scenarios
The hotkey priority
For example when I create a hotkey for a start menu entry (Ctrl+Alt+F7) and use the same entry for a hotkey assignment in configuration the start menu entry has a higher priority. A unified command system solves this problem. A user assigns a value to a command not to a control. This way hotkeys would be unique. Every time a user presses the hotkey the command is invoked. You may create a button, a menu item or whatever for the command but you don't have to if you just want a hotkey.
The dull function key bar
The so called "function key bar" is not really a function key bar. A function key bar should provide the commands currently assigned to the function keys on the users keyboard. Currently the keys F1, F2, F9, F10, F11 and F12 are missing. Instead an unnecessary exit button is provided. Modifier keys such as Ctrl + Alt and Shift should change each button to the appropriate command.
The user can compose the current menu from a list of structure files. For example a user defined structure file can be inserted into the default menu and so on. Similar compositions can be made for all available user interface elements.
Creating commands transparently
When creating a new button to change to another directory a new command is created automatically. This new command will be sorted into the matching category automatically. In this case it could be "Navigation" or "User "Navigation". The command name should be derived from the target directory. This command can now be reused for other interface elements such as menu entries or a hotkey can be assigned easily this way. Other classes of user commands could be "User Programs" or "User Documents". These categories contain commands for launching programs and documents.
The Command Manager should provide a way to delete unused (not assigned to an interface element and not to a hotkey). In addition the Command Manager could search for invalid entries of these user commands.
A command should have the following properties:
- Command - The command to execute
- Name - A unique name (identifier) for the command.
- Caption: A caption which is shown in a control where the action is used.
- Icon: A path to an icon.
- Hotkey(s): One or more default hotkeys which can be used to call the command.
- Hint: A hint which can be shown to give more information about the action.
- Category: Each command is assigned to a category.
- Parameter: Some commands can have parameters.
- Start path: For some commands a start path is required.
- Window mode: For some commands a window mode makes sense (minimized, maximized, normal).
- Run As: Executing a command as a diffrent user (Yes/no).
Design of involved files
Structure files supersede the old menu and buttonbar files. The start menu entries previously defined in Wincmd.ini are moved to a structure file. Structure files define a hierarchy of commands. Calling a structure file can be assigned to a command. This way they can be called from anywhere inside another structure file. You could place them inside a menu hierarchy or on a single button.
Next step: These substructures can be a valid structure file or a hierarchy of commands provided by a plugin. Some structures are dynamically and cannot be stored in a static file. This way you could display a directory hierarchy or the control panel items anywhere.
These files are technically similar to the current menu files. However they don't store any information about hotkeys. Just category and command identifiers can be found here. A structure file starts with a category identifier. It ends with [END_CTG]. This only change from current to the new solution is that CTG is used instead of POPUP. Inside these markers we have the command items (CMDITEM). They just point to command identifiers. Separators can be used here as well.
To support placement on top of a hierarchy and as subelements structure files have to contain a root category which is displayed by Total Commander dependant on the placement of the structure calling command. Example: A main menu structure file is displayed without root when set as main menu. Called somewhere in a submenu the root is required to display a caption for the submenu entry.
If a user interface element doesn't support hierarchy or separators these information are omitted and the commands are represented as a flat list or without separators.
[CTG_MARK] CMDITEM cm_spreadselection [CTG_MYCATEGORY] CMDITEM cm_DynamicStructureAction CMDITEM cm_myCommand CMDITEM cm_myStructureFile [END_CTG] CMDITEM cm_shrinkselection [END_CTG]
Predefined commands file
The predefined command file supersedes the old Totalcmd.inc.
Predefined commands have a static numeric ID. A category is assigned to a command as well. Categories in a structure or commands file can be the same but they don’t have to. It’s possible to add new categories in the structure file or use categories defined in the action file.
The predefined command file also contains a section of hotkeys (shortcuts) which is similar to the current [Shortcuts] section in Wincmd.ini. These are the default hotkeys. Hotkeys must be unique. Therefore they are not stored as properties of commands.
User interaction: This file is never changed by a user. Multiplicity: This file exists only once for every Total Commander installation.
[cm_SpreadSelection] Category=CTG_MARK [cm_ShrinkSelection] Category=CTG_MARK
Userdefined command file
The example shown above is a user defined action. It could have been created automatically by TC as the user created a directory menu item for example. Of course it has been sorted into the appropriate category CTG_NAVIGATION automatically. Please note that there is no ID set for the user defined command. Why? One aim of the unified command system is to make it easier to exchange user defined files like menu files, command files and others. Total Commander has to assign a ID dynamically for user defined commands. This has also the advantage that the user cannot assign an already assigned. This should be possible without huge speed problems.
User-defined command files also contains a section of hotkeys (shortcuts) which is similar to the current [Shortcuts] section in Wincmd.ini. These are the user-defined hotkeys. Hotkeys must be unique. For this reason they are not stored as properties of commands. user-defined hotkeys overrules existing predefined hotkeys.
[cm_CD_Pictures] Category=CTG_NAVIGATION Icon=%WINDIR%\System32\Shell32.dll,127
Predefined Language file
I used caption and hint as two different properties as they are used in Delphi. This leads to a lot of redundancy. A good solution could be make hint optional and use the caption (without the ampersand) instead. This way you won’t get redundancies but still the opportunity to enter longer hints. On the other hand the description could be used for longer hints too. Maybe the hotkey can be moved to the language file. Why? Maybe English users prefare Ctrl+Q for “quick view” and german users want to use Ctrl+ S (Schnellansicht). There are pros and cons for this and can be discussed endlessly.
[CTG_MARK] Caption=&Mark Hint=Mark [cm_SpreadSelection] Caption=&Select group Hint=Select group Description= Selects a group of files and folders based on a filter.
=== Userdefined language file. === The user defined language has the same structure as the predefined language file but contains translations for user defined commands.
[cm_CD_Pictures] Caption=&My Pictures Hint=My Pictures Description=
- The Linux Commander Krusader has such a system but uses an XML-format to store them:
Back to Ideas and suggestions