Request: Unified command system

[Rein de Jong]

Sounds good!
This wil make TC a lot more user-friendly. I myself never changed the start-menu because it affected too much and wil cost me too much time to deal with.
A work around is faster then jump into those config files!

I think your concept wil be a very good thing by most users.

Although I think most users can't imagine the benefits of your idea because they aren't familiar with the change of menu's, short-cuts etc. They just use TC as it is. They even don't use the button-bar or Ctrl-D.

When I am just showing the standard possibilities of TC in a presantation. such as: Multi-rename, extended search, compare en sync dirs, Folder tabs, plugins. Ctrl-Q, most users have no idea this is possible with TC.

Reading help is for Pro's not for dummies
But it would be of help if there were more tutorials and howto's about TC.

[Rhywun]

This is my biggest wish too. Take a look at almost any other modern Windows program: you right-click on the menu or toolbar, and you have access to all the commands and keyboard shortcuts, all in one place. You change the keyboard shortcut or caption for one command, and the changes take effect whether the command is in the menu or a toolbar.

For a long time, I have been torn between Total Commander and one of its competitors who shall remain nameless because of this very issue. You cannot possibly use Total Commander to its full advantage without modifying the shortcuts somewhat and especially the menus - the menus supplied by Ghisler are frankly atrocious . Anyway, the competitor has modern menus and toolbars but it tends to misbehave in rather strange ways so I don't use it. Total Commander's performance is rock-solid - the best of any file manager I've used (I've tried maybe five or six) by far - but the configurability sucks. It's the program's biggest weakness. And it has nothing to do with new user vs. long time user. I submit that anyone who never changes their layout is missing out on features that would make their work much faster.

[Clo]

2icfu
Hello Jeff !

That's exactly the problem... If the button is set to a toggle command there is no clue if the command is set active or inactive.

- Ages ago, I proposed already blurred icons for flip-flop commands "On" in buttons, and normal icons for "Off".
A sword strike in water…
- I knew the Lefteous' proposal, indeed. I'm not against the principle. But it's a huge cake to swallow, with regard to the tiny sweet above which has not been considered…
- I support this presentation, which might define the design of that feature. I mean : that the most users wish, and that the Author should want for implement… A satisfactory balance seems ticklish to establish…
- And, like Xyzzy says, the whole project could appear fuzzy; all users have not the same level and needs; "All" means those who are members of that forum (some %) and the others who are not worldwide (the rest).
 Friendly,
Claude
Clo

[chiron]

@Rhywun: Don't use faked keycodes, and you won't get any trouble with the competitor...

BTT:
I believe this is the never-ending story of TC and the GUI. One faction says: I want to have full speed and a small program

The other faction says: I need a cool-looking and easily customizable program.

It is no secret that TC looks (without any ini-modding or XP-Theme) like a Win3.1 program, and the screenshot on the homepage looks quite ugly compared to the screenshots of the competitor(s).

Maybe there should be 3 Versions of TC: The 16bit, 32bit "classic", and a 32 "enhanced" with a new, modern look, standard toolbars and menus

regards

eric

[icfu]

@chiron:
The unified command system has nothing to do with the GUI on first sight. TC can stay as ugly as it is now and still implement the system, no problem.

@Clo:

But it's a huge cake to swallow

Better one huge cake than 50 little cookies, I'd say.

And, like Xyzzy says, the whole project could appear fuzzy; all users have not the same level and needs; "All" means those who are members of that forum (some %) and the others who are not worldwide (the rest).

It doesn't matter if all people understand the principle, new users won't be able to understand it anyway because they either don't care, don't customize TC anyway or have enough work to do to understand the basic stuff TC is able to offer right now.

But, when the concept will be implemented everyone will benefit, that's the only thing that counts in the end.

Only a minority will ask how stuff works, the rest will say thanks and be happy. It's just the same with all changes happen to mankind. Some people know what microwaves are, some others know how to create them, some others know which material is needed to put them in an oven and to prevent them from breaking out and the majority presses a button and 30 seconds later the soup is ready, no questions left.

Icfu

[WatchUer]

Little to say but Fully Support!

[Sticky]

Fully support. Frankly, I desperately want to become more of a TC nerd, but need a little help. This would be quite beneficial!

[szlori]

Fully support!
I like useful programs with loads of functionality, but I also like programs that are intuitive to use and are consistent from GUI and usability point of view.

Most important points (IMO):
- There should be one common list of hot-keys; you should be able to reassign the predifined hot-keys, but have the possibility to return to the default setting with the press of a button
- There should be one user command editor, and you should be able to assign hot-keys to these commands; and assign these commands to menu items or buttons
- Menus should dynamically show the currently assigned hotkey (corresponding to the command) and checked status (if applicable); you should not define the hot-key in the MNU file together with the menu text!
- Toolbar buttons should have at least 2 types: pushbuttons and radiobuttons; radiobuttons should clearly show the checked/unchecked status

I like the idea very much, that creation of menu files becomes that simple, and that you don't enter any text in it

[robinsiebler]

I fully agree! Modifying the user menu by hand is a pain in the butt! There is no reason for it to be so difficult!

[white]

Generally I believe that whole idea is very profound and stuff, but for a man with maybe a bit different view and not acquainted with discussions on the subject, the presented concept is NOT clear.

Also, I would like Unified command system description more detailed in concepts. As I wrote, for not acquainted with subject it is NOT clear.

I could not agree more. In fact a description of the proposed system is missing altogether!
Only after the questions of Xyzzy and answers to his questions and replies by others, it becomes more clear.

2Lefteous
If you are any serious about your proposal please add a description of your proposal in your first post.
Could you also add to your first post URL(s) pointing to german conversation(s) about the subject. So people who speak a little german can find these conversations easily.
What do you mean by "Unified" in Unified command system? Do you not mean Uniform command system? Or Uniformed command system?

About your proposal, from what I think it beholds. Yes, it would be a valuable improvement. I would be modest at first and change things internally without adding to much features. They can be added later on.

A year ago I posted here an idea for an uniform way of storing Directory hotlist, Start menu and Button bar. Although this is not the same as your proposal, I think it is related.

Command properties
A command should have the following properties:

• 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 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).

[*]Command: The command to execute (forgot the most important one)
[*]Target path: Path to be set in the target window

[icfu]

The point is that discussions are useless and a waste of time until the author shows any interest to implement a sophisticated proposal.

German thread is here:
http://www.ghisler.ch/board/viewtopic.php?t=1074

Linux file manager Krusader implemented the proposal, check here:
http://krusader.sourceforge.net/phpBB/viewtopic.php?t=488
http://krusader.sourceforge.net/phpBB/viewtopic.php?t=553

and finally here:
http://krusader.sourceforge.net/handbook/useractions.html

Icfu

[Lefteous]

The point is that discussions are useless and a waste of time until the author shows any interest to implement a sophisticated proposal.

I showed a lot of patience - I guess too much - but someday even my patience is over.

[Jonas]

I have implemented such a useraction-system in Krusader. Maybe you want to take a look at the Handbook-section about useractions. In the german board I have discussed this unified action system a lot with Lefteous. Finaly I decided to use a xml-based file-format instead of a simple key=value system. The current system has some weak spots, like missing i18n-support but it showes well the power of such a system. If you have a Linux-box somewhere I encurrage you to play with it. It helps improving this concept for TC.
In the current CVS-version you'll find some new placeholders which are not yet documented in the handbook. What is realy usefull is for example the Each-placeholder. It splits up the commandline and executes it for every parameter separately. This makes the complex use uf tools like str2multi unnessesary. I also introduced scripting using JavaScript but this is very alpha and many Krusader-internals are not yet exposed to the scripting-engine (you need to have KJSEmbed installed to use this feature)

What I discoverd during my work on this for Krusader was that it is incredable powerfull if the placeholders can have parameters itself. I hope that TC will also provide something like this some day.

Edit: sorry, I've overlooked the second page

[Lefteous]

2white

...add a description of your proposal in your first post.

What do you mean exactly?

Could you also add to your first post URL(s) pointing to german conversation(s) about the subject. So people who speak a little german can find these conversations easily.

Yes i will do that. However the german thread is very long. I cannot translate the whole thread. I tried to translate the parts I thought they were most important. Maybe I haven't picked the right ones. It's not a "final" concept I asked for help of others. I also don't wanted to make the introducing post to long.

What do you mean by "Unified" in Unified command system? Do you not mean Uniform command system? Or Uniformed command system?

I didn't introduce that term. Another member used it some times and I used it for this thread. I'm always open for improvements. What I mean should be pretty clear.

About your proposal, from what I think it beholds. Yes, it would be a valuable improvement. I would be modest at first and change things internally without adding to much features. They can be added later on.

I agree in general. But new feature which belong somehow to the new command system should be considered in the design process.

A year ago I posted here an idea for an uniform way of storing Directory hotlist, Start menu and Button bar. Although this is not the same as your proposal, I think it is related.

Yes I thought about something similiar. I will add something like that soon. Any type of control container should be treated like a hierarchical list (tree) of controls which can have an assigned command. The logical physical represantation is the same file format.

Command: The command to execute (forgot the most important one)

Yes and no. There is a property called name which is the command id. Internal commands only need such a name. User defined commands have an id (auto generated) too. But in this case we need an additional field.
I have to admit that calling it "name" is probably not very good.
I thought a bit about that. Currently the user can enter a userdefined command or choose a predefined command. That's not so bad (beside from the long ugly list of predefined commands). Maybe it's a good idea to display the internal command or the predefined command instead of showing the command id always.
The result would be a "command identifier" and an optional "user command" field. To the user this is presented as "command" field always choosing the right one as described above.

Target path: Path to be set in the target window

I'm not really sure how that should fit into the current system. The buttons on the buttonbar have such a feature as well as the directory hotlist entries.

[Helix751]

I like and fully support the idea. The fact that a command is an abstract concept that could be indistinctly assigned to a button, menu item, shortcut or whichever else (is there another possibility really?) is intuitive and provides ease of customization and further usability for both advanced and novice users.

I really miss "toggle states" indicators in buttons, as well as iconic menus, which would be much easier and faster to use.

Further, there are much better customized menus built by russian and english guys, but I'm currently unable to use them because they must be translated first. It would be much easier to use these menus and further customize them with the unified command system and a dedicated external menu editor.

Great job Lefteous and I hope Mr. Ghisler may include this in his development plans for TC.