| View previous topic :: View next topic |
| Author |
Message |
halmai Junior Member

Joined: 03 Jan 2010 Posts: 6
|
Posted: Sun Jan 03, 2010 9:37 pm Post subject: wider window during copying/compression |
|
|
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? |
|
| Back to top |
|
 |
halmai Junior Member

Joined: 03 Jan 2010 Posts: 6
|
Posted: Wed Jun 27, 2012 3:56 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
 |
ghisler(Author) Site Admin


Joined: 04 Feb 2003 Posts: 24602 Location: Switzerland
|
Posted: Thu Jun 28, 2012 7:34 am Post subject: |
|
|
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. _________________ Author of Total Commander
http://www.ghisler.com |
|
| Back to top |
|
 |
halmai Junior Member

Joined: 03 Jan 2010 Posts: 6
|
Posted: Thu Jun 28, 2012 8:46 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
 |
umbra Power Member

Joined: 14 Jan 2012 Posts: 662
|
Posted: Sat Jun 30, 2012 9:48 am Post subject: |
|
|
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? _________________ Windows 7 Pro x64, Windows 8 Pro x64 |
|
| Back to top |
|
 |
halmai Junior Member

Joined: 03 Jan 2010 Posts: 6
|
Posted: Sun Jul 01, 2012 3:36 pm Post subject: |
|
|
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. |
|
| Back to top |
|
 |
umbra Power Member

Joined: 14 Jan 2012 Posts: 662
|
Posted: Wed Jul 11, 2012 1:05 pm Post subject: |
|
|
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. _________________ Windows 7 Pro x64, Windows 8 Pro x64 |
|
| Back to top |
|
 |
halmai Junior Member

Joined: 03 Jan 2010 Posts: 6
|
Posted: Thu Jul 19, 2012 8:10 am Post subject: |
|
|
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. |
|
| Back to top |
|
 |
JohnFredC Power Member


Joined: 14 Mar 2003 Posts: 845 Location: Sarasota Florida
|
Posted: Fri Jul 20, 2012 8:36 am Post subject: |
|
|
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. _________________ Licensed, Mouse-Centric |
|
| Back to top |
|
 |
|