wider window during copying/compression

[halmai]

When I press F5 to copy files from one panel to the other one then a small window appears and shows the file paths and names are being copied. If the path is too long then the middle part is omitted and is replaced by "...".

This window is only 4-500 pixels wide although my desktop resolution would allow much wider window. Hence I usually use long dir names and deep directory structures, I usually can not see what is exactly under copying at the moment.

My suggestions are:
- increase this width to 800 or even more pixels
- an automatism could adjust the width of this window, for example 80% of the main TotalCommander window.
- this window should be resizable and the adjusted size should be remembered.

Is this possible?

ps.: the mouse cursor indicates that the window is resizable but it is not. It's size is fixed. Maybe there is some problem on my side? Or is this a bug?

[halmai]

I was waiting for TC80 so much because I hoped that this issue will be fixed. Is there any plan regarding this one? Thank You in advance.

[ghisler(Author)]

Unfortunately it's not that easy to change. Currently the displayed path is shortened based on the length of the string in characters, not in pixels. To shorten it by pixels, I would have to call GetTextExtentPoint many times, which could be a real speed killer when copying many files.

[halmai]

I know, that pixel-width calculation for a string is time consuming. My original suggession was to let the user resize this window and preserve it's size.

[umbra]

I think, I have seen a workaround for this problem somewhere (not sure, if it was in TC or in some other software). In a progress dialog, one could hover mouse over such shortened path and a tooltip would appear with a full path. Wouldn't that suffice?

[halmai]

I don't think a mouseover handler would be less resource consuming for thousands of strings than a simple re-sized window.

I would preserve the present string shortening method based on string length measured in character (and not in pixels) but i would let the user re-size his window.

[umbra]

Most of the time, you don't need to see a full path of a file, that's being copied. Even if you copy a big folder structure, it's rarely useful to see full paths all the time.
With a tooltip, you could get the path anytime you'd actually need it, while keeping the copy dialog itself small. And since it would be triggered per request (not automatically), its speed wouldn't be an issue.

[halmai]

The idea came into my mind when I was copying (or compressing, I do not remember) a huge directory which contained a bunch of backups of a smaller project made every day. So the displayed paths were like this:

C:\archieves\20..\my_log_file.log
...
C:\archieves\20..\my_log_file.log


My directory structure was like this:

c:\
+archives
+2012-01-01
+2012-01-02
+2012-01-03
+...

So the most important part, the backup date was invisible from the path. This caused that I did not know which directory the copying/compression is working on.

Anyway, I suppose that showing the full path requires much less time than opening a file and reading from or writing to it. Right? So the required time what we are discussing about is significantly less than the full time required by the whole process.

If I happen to fail then a delayed path display could solve the problem: no more than 10 times is needed in a second. This means if last path display is older that 0.1 second then it should be overwritten by the new file's path otherwise the old one should be preserved. (Maybe 0.2 or 0.05 second is better than 0.1, this was just an idea.) More than 10 (20?) string display in a second is really useless.

[JohnFredC]

Some method for the user to adjust the placement of the ellipsis in the path string (by interactively dragging the ellipsis, for instance) would be welcome, but failing that, a better algorithm to place the ellipsis would suffice.

IMO, in most situations the folder hierarchy closest to the file itself should have priority for display.

For instance, the following path...

• C:\Documents\Projects\Project1\2012-01-12\Document.doc

...should display so as to preserve (at least) the drive letter and the entire folder name of the containing folder, if possible.

For instance:

• C:\Doc...\2012-01-12\Document.doc

This just seems to be common sense. Otherwise (in many cases) the display/update of the path in the dialog is virtually useless and a waste of resources.