Partially clipped information about copied objects

[streak]

I found that tracker is clipping information about copied/moved objects in tracker window while copying/movine Auto-Manual resize tracker window while copying-moving enhancement should do the trick...

In attachment screenshot with clipped information

[scottmc]

Any chance you'll get to this one in the next week or two?

[yourpalal]

Replying to scottmc:

Any chance you'll get to this one in the next week or two?

I'm not sure right now, I'll have to take a look at the source, but IIRC, it is non-layout code, so it might take a bit longer. I will post once I can get an estimate of how long it will take to track down/fix the problem.

[yourpalal]

It looks like the changes won't be too drastic, although we'll need to decide what to truncate or move, but I'm having trouble replicating this. In particular, it is hard to find something that takes a long enough time to copy to properly observe the window.

[Disreali]

Replying to yourpalal:

It looks like the changes won't be too drastic, although we'll need to decide what to truncate or move, but I'm having trouble replicating this. In particular, it is hard to find something that takes a long enough time to copy to properly observe the window.

Try moving the Haiku trunk to a new location. As for what to change, I think splitting the info under the progress bar into two lines would be good.

example:

Moving: Haiku           <many # of files>
////progress-bar///
To: <new location>/Haiku
100MiB of 2.96GiB  @ 2.5MiB/s

Hope this helps.

[axeld]

Copying a large amount of files, or a large file helps to bring up the estimation, especially when copying to a slow medium like a USB stick.

Besides making the window a bit wider, I would also like to have a tooltip with the current information (ie. complete, the view itself switches between estimated time, and copy speed).

[yourpalal]

dialog appeareance with patch applied

[yourpalal]

I've attached a screenshot of the window, with my current patch applied. Basically the strategy is:

• if possible, show both the full destination and full status message
• if that is not possible, show the abbreviated message
• If needed, truncate the destination with B_TRUNCATE_MIDDLE

The reason I chose this is that truncating the status message would make it basically unreadable, and probably offer little space savings. The destination is truncated in the middle, as I believe that is the standard behavior for truncating paths. I haven't done it yet, but I think the window might as well be a bit wider, so I will do that too, but the basics of the patch will stay the same.

Furthermore, I like the idea of adding a tooltip, and I did a bit of refactoring with that in mind, but I want to open a separate ticket for that.

[humdinger]

Correctly trunkating is very much appreciated. Would it be easily possible to have the status window resizable and remembering its width, like the mail_daemon status when fetching/sending mails?

[yourpalal]

Replying to humdinger:

Correctly trunkating is very much appreciated. Would it be easily possible to have the status window resizable and remembering its width, like the mail_daemon status when fetching/sending mails?

:) Yes, that could be done by (most easily with the layout API). However, I would file that as another ticket as well.

[yourpalal]

Fixed in hrev40685.

[diver]

BTW clicking Pause button freezes Tracker status window after this revision.

[yourpalal]

Replying to diver:

BTW clicking Pause button freezes Tracker status window after this revision.

Uh-oh, I'll look into it! Thanks for the heads up!

[yourpalal]

Replying to yourpalal:

Replying to diver:

BTW clicking Pause button freezes Tracker status window after this revision.

Uh-oh, I'll look into it! Thanks for the heads up!

For reference, this was fixed in hrev40698 by Stippi.