25995 - Download manager (multiple downloads per window)

Status: VERIFIED DUPLICATE of bug 102477

(Core Graveyard :: File Handling, enhancement, P3)

Description

[sarnold]

One feature I would like to see is a single "download window" -- one window,
with the names of all files being downloaded, size, statistics, and a "kill"
button for each.

My reason: I think it is plain silly to reduplicate the same title bar, window
decorations, etc, for each individual downloading file -- I think a nice tabular
view of all the files being downloaded (perhaps an explorer-like tree,
heirarchical on server/path? Just a thought.. :) with the easy ability to stop
any and or all of them would save quite a bit of space, and make a certain
amount of sense. (Hmm, I just had another idea -- I sort of liked the html
newsreader netscape introduced back in navigator 2.0 or so.. could a dhtml
document be put together to track the downloads in a browser window? If done
properly, that could allow the user/company to customize as they see fit. :)

-- "thinks 1600x1200 is too little screen real estate"

Thanks :)

Comment 1

[leger]

Putting on eng radar as enhancement

Comment 2

[Paul MacQuiddy]

spam: moving qa contact on some bugs from paulmac to [e-mail]

Comment 3

[Matthew T (active 1999-2002)]

Resummarizing so I can find this bug again in future.

This would be cool as a sidebar panel, too.

Comment 4

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 5

[Peter Lairo]

This sounds like a neat feature, particularly the suggestion to put the list of
download files in mysidebar, or as an option in ONE small download window.

Anybody working on this?

Could this feature also include "resumable" downloads?

Comment 6

[timeless]

note to self: dupe this against the bug that has more useful and detailed 
specs.

Comment 7

[Peter Lairo]

This feature could be combined with an INTERNAL download manager ala GetRight,
for which i am filing a bug report today.

Comment 8

[Peter Lairo]

Please also see bug 64887 for integration of this feature into a built-in
"Download Manager".

Comment 9

[tor]

*** Bug 64887 has been marked as a duplicate of this bug. ***

Comment 10

[sarnold]

mozilla0.8 keyword added from suggestion by [e-mail]; I too would like my
screen real-estate back when I get several downloads going at once. I'm not sure
I can suggest putting them into the sidebar only, since the first thing many
people do is turn the sidebar off.

However, if it is decided that mozilla0.8 is not an acceptable keyword for this
bugreport, I won't shed tears if it is removed.

Allow me to restate my original hopes for this bug report -- I can't see a good
reason to waste so much screen space for individual download windows -- so much
duplication. *I* would be satisfied with something very simple -- name, progress
bar, 'kill' button, for each file being downloaded.

I am not asking for a GoZilla! sort of deal. That can still be provided by
GoZilla! for all I care. I just want screenspace back, while seeing which files
are downloading how quickly.

Cheers

Comment 11

[Thomas Betz]

"I'm not sure I can suggest putting them into the sidebar only, since the first
thing many
people do is turn the sidebar off."

You have to put more cool features into the sidebar if you want people use it.
Somekind of a download manager would be VERY cool. Just a simple one..."download
later" or "scheduled download" would be nice.

Comment 12

[sarnold]

That is a perspective I hadn't considered. Good point.

Comment 13

[Matthew T (active 1999-2002)]

> You have to put more cool features into the sidebar if you want people use it.

And if you keep pushing people around like that, making them use the sidebar when 
they don't want to, you might just encourage them to stop using Mozilla 
altogether.

Comment 14

[Thomas Betz]

then make all this download manager stuff accessible through the sidebar AND a
window for people who dont like the sidebar...that would solve the problem :)

Comment 15

[Peter Lairo]

The ONLY problem I see is that we need to see the progrees for EACH download in
the taskbar (bug# ?), because most people will move the download window to the
background where the progress is no longer visible (to continue surfing).

There should be an option in prefs:
 <x> show each download in their own window (default)
 < > show all downloads in one window (progress summary % in taskbar possible?)
 < > show downloads in sidebar

Maybe there should be a sidebar tab that one could view regardless of the option
chosen (eliminating the need for pref option 3).

Comment 16

[Peter Lairo]

All download manger features are now being tracked by meta bug 75364 - "[META]
Download Manager Features"

Therefore this summary needs to be changed to: 
[RFE] Multiple Downloads per Window (Download manager)

Also, need to add "Bug Blocks" bug 75364 above.

Comment 17

[Matthew T (active 1999-2002)]

*** Bug 75364 has been marked as a duplicate of this bug. ***

Comment 18

[Peter Trudelle]

You might also consider folding the progress meter into the file icon itself, 
showing the icon 'filling up' as the operation progresses, as was done many 
years ago in Stuffit for Mac. This allows simultaneously showing file type, 
creator (on Mac), thumnail content (for images), and download progress.  Lots of 
pertinent info, compactly presented, yet obvious at a glance.

Comment 19

[sarnold]

Oi! It sounds like a lot of work to putz around with an Icon. While it may Look Cool I have trouble believing it is more useful than a simple progress bar.For an example of what I am roughly after, check out Konqueror's "show network operations in a single window" option. It has exactly the flavor, size, and features I want from such a window. Well, it isn't perfect; however, I think it is a wonderful starting point to build on.

Comment 20

[[e-mail]]

Would it be possible to show internal downloads e.g. images on pages?

Comment 21

[Viswanath Ramachandran]

sending to law for future work. 

Comment 22

[timeless]

Download icon status is a bug somewhere, however, if we do that, we'd need to 
offer an access way of getting download status for the blind.

Comment 23

[Andrew Thompson]

Its not 'hard' to do the "bar in the icon" stuff on Mac OS, ie and iCab do it. 
The reason its easy is Apple actually provide an API to support temporary changes 
to icons in the operating system.

Seems quite esosteric. I wonder how it got in there...

Comment 24

[sarnold]

Fine. Implement it for Mac OS {8,9, others?}. This means either the Mac API is 
reimplemented by the mozilla team on other platforms to maintain cross platform 
look and feel, or the mac is special (which is fine for those users but will double 
the code base dedicated to any download manager), or they can just make a stupid 
progress bar collector window for their web browser. Would you rather they spend 
their time making pretty icon thingies or making a web browser?

No, the fact that this bug has been open for nearly 1.3 years makes me pretty sure 
there is no point in continuing this thread. A download manager (as simple as 
konqueror's!) is not a priority for the mozilla team. Learning javascript is not a 
priority for me, so I am not about to do it. Learning javascript doesn't seem like 
a priority for others who have voted for this bug.

It may be easier for all concerned to just assume that this bug will never be 
addressed and save all our time.

Comment 25

[Alex]

Wait a second there sarnold. Many of us, who report bugs and make suggestions,
like you and I, don't know a thing about the C++ or whatever to get our requests
off the ground and into reality. All I've wanted out of this bug is a single
window that lists all my current downloads, some numbers on its progress, and
the ability to stop each download. No fancy icons or whatever, just a single
window to clear up the clutter of having multiple windows when I'm downloading
several things at once.

All fancy features should be left to third-party programs, since I think Mozilla
should only provide the basics for such a feature.

Comment 26

[Matthew T (active 1999-2002)]

Updating the file's icon to show progress is a valid RFE (and yes, it would be 
possible on Windows too, sorta). But that's completely different from this bug; 
it's bug 71657.

sarnold: It's very true that Bugzilla isn't the place for `threads'. It's also 
true that programmers from this mythical `Mozilla team' won't magically appear 
out of thin air to satisfy your every demand. Programmers generally do either 
what they get paid to do, or what interests them. So if you want this 
implemented, your best bet is to pay someone to do it, or to make someone want 
to do it themselves. And for the latter, moping in Bugzilla is not a 
recommended method.

Comment 27

[Alex]

Speaking of having someone else program this, what exactly would it take to get
something like this, in its most basic form, off the ground? Perhaps I'm being
naive at this, but I do know HTML and CSS so I could learn XUL, and I understand
programming concepts, know a bit of C (actually PHP, which derives off of C),
although not JavaScript but I do have a book on it. I don't have a complete
understanding of how different parts of Mozilla works, but I do know that XUL
and JavaScript do play important roles.

If the effort that's need is somehow within these parameters, and it doesn't
require that I have to compile Mozilla on my own machine, I'm willing to give
this a shot.

Comment 28

[AriB]

I'm voting for this feature on condition that if mozilla crashes it wouldn't
take down any downloads with it

Comment 29

[Ben Goodger (use ben at mozilla dot org for email)]

Adding URL to Download Manager proposal (Microsoft Word document)

Comment 30

[basic]

Attachment: image from doc file

Comment 31

[basic]

Attachment: image from doc file

Comment 32

[basic]

Attachment: doc converted to html

Comment 33

[Håkan Waara]

I didn't read all the text (sorry), but here are some comments on the screenshot:

1. Let's be consistent with the K vs. KB (downlaoad file rate and file size)

2. If we're downloading a web page, we should have a twisty so you can hide/show
the individual files download.

3. I don't like the text-only toolbar (similar to the bookmarks one). I'd much
rather just have us use menus or have icons (too).

4. How about using the text version of > and < ? Less than and More than, perhaps.

That's all for now. Good job on the spec Ben!

Comment 34

[timeless]

I think we're settling on KB, but i don't remember s vs. sec.

banner.png is messed up:
<30% complete <1 min    9KB of 9KB  @ 3.4KB/s
if you're not sure please use the indeterminate indicator (or do we spec 
something else?).

In general:
stuff.zip Complete 34KB.
* No need to indicate 100/100 it's silly, it's complete.
Work Done 25% 25mins 25MB of 100MB  @ 6.2KB/s
* don't repeat MB, use only at tail, so 25 of 100MB
* I'm noticing i abbreviated minutes.  If the col shrinks it should definitely 
be abbreviated, otherwise this should be considered.
Always Show Extension!!! By default anyways, especially for microsoft 
documents.

foo.pee     1% 100mins 90Bytes of 2MB @ 5KB/s
if the units don't match, do show them.

set a threshold for changing units, probably 2024.

space between xKB should match the decission from elsewhere - bug 88666.

Scan for viruses. AIM-p.

Show in finder should probably consider using the text from the current 
downloader window.

Filenames should use crop=middle, 

MIME Type should be an optional collumn

Personally I'd like to be able to enter a url into the download manager. [1.1]

File properties, should be able to change type (esp for macos, but also for 
others).

Coollumns should be sortable, sorting would not be global, so history.html and 
banner.png would always be together (unless you allowed decoupling, and i don't 
see a benefit in doing that).

Download Date collumn, please. if you like the windows/bookmarks/history 
systems you can have two dates, but otherwise start date for unfinished 
transfers and possibly end time for finished transfers.

Given your likely binding for Delete i'd suggest 'Remove'.

Drag and drop support?

Comment 35

[Matthias Versen [:Matti]]

*** Bug 92943 has been marked as a duplicate of this bug. ***

Comment 36

[sairuh (rarely reading bugmail)]

should this be reassigned ben...?

Comment 37

[sairuh (rarely reading bugmail)]

over to ben, since i think he's working on this. not sure what the target should
be, so tentatively setting at moz0.9.6.

but do reassign/retarget as needed!

Comment 38

[jlarsen]

*** Bug 101725 has been marked as a duplicate of this bug. ***

Comment 39

[Jerome Lacoste]

I've posted a duplicate of that bug (bug 101725).

I didn't see it because I had done a query on 'enhancement' bugs.
Shouldn't bug 25995 be an enhancement?

Anyway, some of the ideas I have in the bug report may perhaps be added to this
one (e.g. groups of bugs, freeze all bug one, persistence...).

Regarding the 'should we allow a user to have a separate window for a specific
download, I think it brings more complexity than interest. I think it is a risk
for more bugs.
I will read the proposal for further comments.

Comment 40

[Ben Goodger (use ben at mozilla dot org for email)]

-> mozilla 1.0

Comment 41

[xyzzy]

*** Bug 102836 has been marked as a duplicate of this bug. ***

Comment 42

[Peter Trudelle]

Since this is now on my team's schedule, I'd like to start using this bug as a
metabug for planning this feature and tracking the design and implementation
(for which we'll create separate dependency bugs). Current working plan is at
http://mozilla.org/xpapps/MachVPlan/Download_Mgr_estimate.html . Please do not
use this bug for protracted discussion of the feature. Instead, review our
design and plan, conduct any discussion in the appropriate newsgroup
(browser/UI/perf/?), and add links to that discussion here. The plan and design
both need review, to be indicated by r=.

Comment 43

[Christoph.Vogelbusch]

Instead of opening a new bug I want to add a few ideas to this old wish.

For the perfec download behavior of Mozilla (and to make EVERYBOY haooy) you
should make it have the following features (sorted by implementation, first
should be done first last is more an additional feature):
- first the current download windows should get percentagein their title bar.
- second you should make a download window with statistics, where those windows
can be swallowed to (or be swallowed as default) (I know some that like to havbe
multiple window wiht percentage (at least for some downloads)
- third the download window should save download list so it could resume after
mozilla crash or ecxit.
- fourth download should be able to remain in list (even after downloaded) till
someone kills them, so people se what's done and can start them directly from
the download window.
- fith (and les important), alternative download sites could be searchable
though ftpsearch etc.

Comment 44

[Peter Trudelle]

No!  This is not a wishlist, we will not be discussing possible changes to the
feature itself in this bug report.  If we can't use this bug report to plan and
track the work (you do want to see this work done, right?), then we'll open
another bug, behind our firewall if necessary, and ignore this one.  Please
discuss in the appropriate forums, not here.

Comment 45

[sairuh (rarely reading bugmail)]

spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)

Comment 46

[sairuh (rarely reading bugmail)]

ben's orginal Word doc is at
http://www.silverstone.net.nz/work/Download%20Manager.doc --but here's the
html'ized version as well: http://mozilla.org/xpapps/MachVPlan/DownloadMgr.html

Comment 47

[Peter Trudelle]

Let's make the mozilla.org html version the official copy, better it were the
only posted copy.

Comment 48

[Ben Goodger (use ben at mozilla dot org for email)]

*** This bug has been marked as a duplicate of 102477 ***

Comment 49

[Adam Hauner]

BTW could voters move their votes to bug 102477? This bug has 17 votes, 102477
has now just 3... 

Comment 50

[Peter Trudelle]

Please don't waste your votes on on either of these, vote for something that
hasn't already been targetted for the next release cycle.

Comment 51

[sairuh (rarely reading bugmail)]

mass verification of duplicate bugs: to find all bugspam pertaining to this, set
your search string to "DuplicateBugsBelongInZahadum".

if you think this particular bug is *not* a duplicate, please provide a
compelling reason, as well as check a recent *trunk* build (on the appropriate
platform[s]), before reopening.