His reasoning was that the last part of the file is the most important for most people / use cases. This use case is recursive retrieval where once you're a couple levels deep, actually knowing the filename could be difficult with the current scrolling mechanism.
I've attached a patch which reverses the direction of the scrolling. The patch is currently only a proof of concept and will be changed and cleaned for the final version. However, I'd like everyone's views on the direction of scrolling and how it looks reversed. I believe that after reversing it, the progress bar may be more useful in a recursive retrieval, but looks a lot worse.
My suggestion is to add another option to the --progress=bar switch, something like this: --progress-bar:rtol and --progress=bar:ltor for switching between the two scrolling styles, with rtol (Right to Left) being the default.
-- Thanking You, Darshit Shah
From d020b51aeb4bf281fd6722a85489c6c9cbdcd3bc Mon Sep 17 00:00:00 2001 From: Darshit Shah <[email protected]> Date: Thu, 27 Nov 2014 13:35:58 +0530 Subject: [PATCH] [RFC] Reverse scrolling direction --- src/progress.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/progress.c b/src/progress.c index 479eaff..1e215d9 100644 --- a/src/progress.c +++ b/src/progress.c @@ -981,7 +981,7 @@ create_image (struct bar_progress *bp, double dl_total_time, bool done) bytes_in_filename = cols_to_bytes (bp->f_download + offset_bytes, MAX_FILENAME_COLS, cols_ret); - memcpy (p, bp->f_download + offset_bytes, bytes_in_filename); + memcpy (p, bp->f_download + strlen(bp->f_download) - offset_bytes - bytes_in_filename, bytes_in_filename); p += bytes_in_filename; padding = MAX_FILENAME_COLS - *cols_ret; for (;padding;padding--) -- 2.1.3
pgpj8L_DExZ8e.pgp
Description: PGP signature
