[req] more button options

[nsp]

It would be Great to have :

MultiPush Button with one command by mouse click type
LeftCmd, LeftParameters
RightCmd, RightParameters
MidCmd, midParameters

On/off button with one command by mouse click and state
LeftCmdOn, LeftParametersOn, LeftCmdOff, LeftParametersOff
RightCmdOn, RightParametersOn, RightCmdOff, RightParametersOff
MidCmdOn, midParametersOn, MidCmdOff, midParametersOff

Filtered button
(EXPRESSION 01 ) | Cmd | Parameters |
(EXPRESSION 02 ) | Cmd | Parameters |
(EXPRESSION 03 ) | Cmd | Parameters |
(EXPRESSION 04 ) | Cmd | Parameters |
(EXPRESSION 05 ) | Cmd | Parameters |
(EXPRESSION 06 ) | Cmd | Parameters |
.........................................................
(EXPRESSION 28 ) | Cmd | Parameters |
(EXPRESSION 29 ) | Cmd | Parameters |

Where Expression is a DetectString expression like in content plugin.

[nsp]

..... Someone proposed (but the message disappeared) also to have an animated image as icon and the ability to have actions for each frame of it ...... 200 frames * 200 buttons * 3 keys modifier * 3 mouse click type => 360000 commands .....

In fact, we can have much more than this if we consider key modifier
as CTRL, ALT, WIN, ShiFT and combinations => 12 modifiers
button state 2, 3 mouse click and DblClick ....
The result is even more impresive ... 5760000 cmds

if we do 1 cmd by second during 8 hours a day we can spend almost one year to experiment all the command .................. This is really impressive

__ __ ___ ___ ___ ___ ____ _____ _______ _________

To be more serious : Powerpro already have one action per type of mouse click and i use it always for my bars. I would like to have this in TC, technically it is not so difficult to code !!

I like to have packed button bars... and only one action per button is not sufficient for my use...

[icfu]

LMB, RMB and MMB actions would be nice to have, Directory Opus has it for example. I have proposed it in the past already.

But I don't understand that on/off thing. And what does this expression thing mean, do you mean a button that does a different action regarding the filetype you drag&drop on it?

Frame aware actions? Oh, well...

Icfu

[nsp]

LMB, RMB and MMB actions would be nice to have, Directory Opus has it for example. I have proposed it in the past already.

Thx for your support, I know that some stuff have been already expressed but why not re-express some of our needs fo TC7...

The on/off button is a "toggle button". on action when you push one when you pop

For the Filtered button you are right, the filter have the same notation than DetectString (used for lister, content,...)

With this we can have a ChoiceEditor in a button. It could also be possible to have some automatic reorganization button (*.mp3 go to music, html, doc go to DOC, *.avi go to movies, Zip, rar 7z SQX go to Archives...)

[icfu]

Thx for your support, I know that some stuff have been already expressed but why not re-express some of our needs fo TC7...

Sure, I don't even think that I have created a separate thread for that...

I like your proposals, this is what I can say, but many problems would have to be solved first before such things can be realized. For example TC must be equipped with internal lst2str and lst2run functionality.

Some things can already be done in AHK pretty easily by the way (moving by extension, ChoiceEditor functionality, modifier aware buttons), so if you need to do things NOW, maybe it's time to give it a try, if you haven't already done so.

Icfu

[m^2]

And one more possible use:
Do you know WAC? It's a part of TWinamp. A program to control winamp from button bar. I wrote similar tool for XMPlay.but it has one disadvantage - XMPlay has one button (and one command) for play and pause. And currently I have to use one icon for both...On/off option would be salvation.

[icfu]

If you are using a button bar for controlling Winamp you can easily solve that by using two nested button bars.
Check this to get an idea:
http://www.totalcmd.net/plugring/bar_creator.html

Icfu

[nsp]

Some things can already be done in AHK pretty easily by the way (moving by extension, ChoiceEditor functionality, modifier aware buttons), so if you need to do things NOW, maybe it's time to give it a try, if you haven't already done so.
Icfu

I do some stuff today but with powerpro and bat files not AHK I have already PPro as Shell. I do not want to add another KeyTrap Automation tool (AHK) in background.....

[icfu]

AHK is not meant to be ADDED to PP, it's meant to REPLACE it.

Of course, if you are so used to it, I can understand why you stick with it. I got mad when using it several years ago, it has more configuration options than stars in milky way.

Icfu

[m^2]

If you are using a button bar for controlling Winamp you can easily solve that by using two nested button bars.
Check this to get an idea:
http://www.totalcmd.net/plugring/bar_creator.html

Icfu

I don't see it.
What I want is:
It XMPlay is playing - button has "pause" icon.
When I click it - it changes to "play".
How can I do this with nested bars?

[Lefteous]

There are two types of suggestions for features I wouldn't use.
- Functions I wouldn't use.
- Functions that I wouldn't use but also overload the interface.

This is the second kind and that means I have to interfere. Please save the simplicity of buttons!

[icfu]

@m^2:
You create two button bars which are only different in ONE icon:
In the stop.bar the stop button is pressed and the play button is released. As soon as you click PLAY, the play.bar is loaded which has the play button pressed and the stop button released.

So, what you need to do is:
1. Create two em_commands: em_Load which loads the play.bar and em_Stop which loads the stop.bar
2. Create two AHK scripts (or any another scripting tool or program of your choice): the first script sends em_Play message to TC and the play message to XMPlay, the second one sends em_Stop to TC and a stop message to XMPlay.

So far the theory, but I have just seen that TC doesn't offer a possibility to switch the buttonbar using an internal command....

Any ideas? Maybe I am also overlooking such a command right now...

Edit: I have made a request for cm_LoadBar:
http://ghisler.ch/board/viewtopic.php?t=12878

Icfu

[icfu]

@Lefteous:
It's ok if you don't use your mouse, other people do...

Content specific awareness is very special, I agree, but the rest is so obvious and useful.

Icfu

[nsp]

@Lefteous:
It's ok if you don't use your mouse, other people do...

Content specific awareness is very special, I agree, but the rest is so obvious and useful.

Icfu

@Lefteous The implementation of multi button is not so difficult and it can be useful for some people as state icfu !
Your point is if M. Ghisler spend 2 hour with this crappy feature he will nat spend time for all my wonderful propositions..... I admit i share your vision, we only do not use TC the same way !

The content specific stuff is special but it's a a way to have generic button/action (you can even have it for em_cmd and launch it with your favorite hotkey...
Right now i do it with batch and i will probably try to implement the detect string stuff in an external command for TCBL.... I can live without having it, but I continue to think that it is something to explore...

[JohnFredC]

From their opinions expressed herein, the most influentual voices in TC's direction (including the author of this wonderful software) appear to be mainly keyboard-centric and because of this do not seem to have experience with developing innovative mouse-centric interfaces.

My take on this is that...

A possible majority of core TC users have primarily repetitive file activities to perform (such as large-scale server/network management), and can keep the entire scopes of those activities "in their heads" and at the tips of their fingers. For them, a fluid/configurable mouse-centric GUI is not really needed... or at least the implementations they have tried slow them down. There are a lot of bad implementations of mouse-centric file managers out there, no denying.

For others of us (myself included), use of TC is more than 50% ad hoc. For ad hoc users, cognitive research has shown over and over again that a properly designed pointer-centric (ie, mouse-centric, for most of us, but styli & tablets are on the way) GUI is overwhelmingly easier to learn and faster to execute for the majority of users.

It's not the fact of a mouse/pointer-centric GUI that is the problem, but its implementation. Just because there hasn't been a good implementation doesn't mean it isn't possible.

The problem for all of us here is that TC is so overwhelmingly more functional (and reliable!!!) than nearly any other file manager that we are compelled to use it as our main tool, despite its mildly goofy implementations like the button bar config, or the really-not-so-new-but-newly-represented "folder trees".

Perhaps if the keyboard-centric users who post here also worked daily (and heavily) in tools which have powerful, flexible, configurable mouse/pointer-centric GUI interfaces (any MS Office product, for instance, or Corel Paintshop Pro, or any number of 3-D modeling packages, Rhino or Maya in particular come to mind) their opinions about how to approach file manager GUI design and customization (even within the restrictive context of the "standard" dual-pane commander paradigm) might change.

I have my flame-retardant suit on... flame me all you like.