Total Commander

Total Commander is a two panel file manager. On the other hand performing file operations which affect just one panel are also frequent operations. Escpecially unpacking an archive to a subdirectory of the current file panel is one of the few tasks which is quite cumbersome in Total Commander. Currently there is just cm_CopySamePanel.
The fact that Total Commander 7.5 will have a one panel mode might be another reason why we need a thorough support for same panel operations. This definitely includes a good choice of consistent default hotkeys for these operations.

Support+

2Lefteous
Niece idea but I think that it would be better to give some predefined shortcuts configurations to choose during installation procedure (it was been discussed in the past).

2fenix_productions
Well I don't see how these suggestions contradict. You can't make any hotkeys or hotkey configurations without commands.

2Lefteous
You're right.

Looks like I misunderstood something.

PS. Maybe we should think about which commands are needed?

My quick proposals:
- copy / move / pack / unpack to right tab,
- copy / move / pack / unpack to left tab.

 

fenix_productions wrote:My quick proposals:
- copy / move / pack / unpack to right tab,
- copy / move / pack / unpack to left tab.

Support++
 

fenix_productions,

- copy / move / pack / unpack to right tab,
- copy / move / pack / unpack to left tab.

What do you mean by left/right tab? The tab to the left/right of the current tab? Or the left/right panel? If the panel, would it not be better to rather have commands for active panel / inactive panel instead of left/right?

Just my 0.02 Euro
Roman

I think what is meant is left/right 'panel'.

But Lefteous began this thread with reference to a 'Single Panel' mode. Should we now be speaking about left/right panels?

Let's fix the SPM questions first, eh?

Or is unpacking a file a factor in SPM?

We see a packed file in TC SPM and we want to do... what? Extract all the internal files to the current folder - even though they may be mixed into tens of other files already there? That would be messy in my Archives folders, for instance.

Would we consider an auto-created folder from, say, Xclock.zip being [!Zip-Xclock] and all the contents being copied into that folder? A new folder under the current packed file's folder. Alternatively, put the new folder in the Desktop.

I'm suggesting the [ and ! so as to keep the new folder near the top of the list. Maybe not both; [[!Zip-Xclock]] may be unnecessarily distracting.

Or [Xclock-Zip] to keep it in close proximity to the source file..?

Each TC file action that requires a target path or object is initiated by a user within a complicated context of possible targets... the user's destination or target "cloud", if you will. The populations and relative priorities of targets in the user's "cloud" differ according to task contexts (what is the user attempting to do?), navigation contexts (which paths/files are already at the surface of the UI?), and UI status contexts (is the task from/to a panel? from/to a tab? from/to an external application?, etc.).

The population of possible targets includes:

• Opposite panel
  Same panel
  Tab
  Favorite path
  Previous path
  Ad hoc path
  Toolbar button
  Toolbar
  Archive
  External (non-TC application window)
  Desktop shortcut
  Etc.

The reasons that TC treats the "opposite" panel as a favored target for file actions are obvious. They are the raison d'etre of the dual-panel interface. Some targets (such as a path in the source panel, in the opposite panel, or in a specific tab) are naturally at the surface of the TC interface, and benefit from ease of UI access. But others, such as a path favorite or a path buried in panel history (or the user's memory) are "below the surface" and require additional navigation to access/designate, the worst case being an ad hoc destination without precedent.

The issue (specifically for the "same" panel, and more generally for all destinations) is: how deeply buried in the UI's navigation hierarchy is "my" desired target? The more deeply buried, the longer (in time and effort) becomes the task of telling TC which destination or target to use, and the less efficiently TC behaves.

If a user needs to be (or prefers to be) prompted for the target parameter, which targets are the best candidates to display at the surface of the prompting UI? Also, what is the most efficient UI sequence in which to present them?

This is an area of TC where the user interface (in particular the copy/move/pack dialogs) doesn't "reach down" very deeply or efficiently.

• 1. TC needs an interface that prompts for more destinations than it currently does. I mentioned this 5 years ago in a post and even presented a mockup solution. Something like that dialog, or components of it, is needed.
  
  For instance, the addition to the copy/move dialogs of an history (or favorites) path drop-down and a direct access "source panel" button would suffice for the majority of path destinations.
  
  2. A further improvement would be for the user to be able to assign which targets are directly prompted for by the interface (and under what circumstances) and, to a certain degree, in what priority or selection order they should appear in the UI control hierarchy.

Naturally, parameterized versions of the internal copy/move/pack/unpack/etc commands would be useful, too.

Lefteous wrote: we need a thorough support for same panel operations.

Would be Highly welcome. :thumpsup:

Support +=

I think navigation to the target path cannot be done more efficiently in a complex copy/move dialog compared to navigating in the target panel. This would just add complexity.

There is an exception to the above stated rule. If the target path is displayed in the source panel. That's why I requested more same panel operations.

2Hacker
I thought about the same panel as Lefteous mentioned in first post.

BTW I was 100% sure that I had answered about 20 minutes after your post but it looks like either Opera or Forum's engine ate it

Lefteous wrote:I think navigation to the target path cannot be done more efficiently in a complex copy/move dialog compared to navigating in the target panel. This would just add complexity.

There is an exception to the above stated rule. If the target path is displayed in the source panel. That's why I requested more same panel operations.

I agree that the dialog is an added complexity. But the benefit of the dialog is that it allows TC to maintain the context of the primary panels during the user's navigation to a target destination not on the UI surface.

Perhaps a "quick return here" or "jump back" checkpoint functionality would help with that issue.

I use F5 a lot and really hope for enhanced dialogs!

But the benefit of the dialog is that it allows TC to maintain the context of the primary panels during the user's navigation to a target destination not on the UI surface.

There is no reason not to change to a target path in the target panel. To switch between completely different paths the directory menu or tabs should be used. Actually the only reason why the second panel exists is pointing to a target path.

Perhaps a "quick return here" or "jump back" checkpoint functionality would help with that issue.

This is how I currently perform a same panel unpack operation:
1. Set same path in target panel
2. Unpack (this is actually more than one step but this is another story)
3. Use the go to previous dir command if the previous path is the target of another operation.

So there is already such a command.

fenix_productions,

I thought about the same panel as Lefteous mentioned in first post.

Ah, ok, thanks.

Lefteous,

This is how I currently perform a same panel unpack operation:
1. Set same path in target panel
2. Unpack (this is actually more than one step but this is another story)
3. Use the go to previous dir command if the previous path is the target of another operation.

BTW, why not Alt-F9, Delete, Enter?

Roman