Merge transfers, queued files and finished files

Bug #406298 reported by David Prieto on 2009-07-29
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

I think that having downloads and queued files in different places is counterintuitive from the user's point of view, since they are both things you want to download. The only difference being, the first are already being downloaded and the second aren't yet.

Dcsharp handles this gracefully, and I propose using a similar layout:

-Transfers shouldn't be shown in a pane but in their own section, together with queues. Using an icon before the filename should be enough to tell them apart, e.g.: a downward arrow for downloads, an upward arrow for uploads and a pause or clock icon for queued items.

-Everything should be based on expanders: the top level shows folders or individual files and from there you can perform transfer-related operations, like removing a file from the queue. Expanding those, the actual connections are shown. From there you can perform actual user operations, like giving a user a slot or removing him from the queue.

I'm attaching a quick mockup.

Steven Sheehy (steven-sheehy) wrote :

I like the idea and in fact I've thought about this before after using bittorrent clients like Deluge. You could also go a step further and include finished downloads since they are just downloads in yet another state. However, I'm not sure how technically feasible it is since the DC++ core was written with these three areas as separate since that's how the Windows DC++ is. It would require a lot of work to implement if it can be implemented at all without asking DC++ to change their user interface as well.

Changed in linuxdcpp:
importance: Undecided → Wishlist
status: New → Confirmed
summary: - Merge transfers and queued files
+ Merge transfers, queued files and finished files

"You could also go a step further and include finished downloads since they are just downloads in yet another state"

Yes, that would make sense.

By the way, I included another mockup related to this in bug #406062:

Steven Sheehy (steven-sheehy) wrote :

DC++ devs, what do you think about this proposal of merging transfers, queued files and finished files into one window? I can see in the latest DC++ commit by arnetheduck that he has added some initial work to move the finished downloads functionality into queue frame. Transfers, queued files and finished files are all just different states of files being downloaded or uploaded, so why have them in separate windows? We could probably implement something in LinuxDC++ on our own using the existing APIs, but it would be nicer if we had upstream support as far as providing more suitable core APIs for the various interfaces to utilize.

Jacek Sieka (arnetheduck) wrote :

That's the plan more or less, although the connections window might stay in some form (what used to be the transfer window that it's connections, downloads, uploads)...the "connections" window could be merged into a "users" window as maybe, that would show all, connected, favorite, etc etc users and downloads would go to the queue...but I haven't quite decided yet, it's kind of nice to see a brief of what's taking up bandwidth without having to open up another tab...

Dmitriy Larchenko (neokril) wrote :

I like this idea. Merged transfers window could be like main window of Transmission bittorrent client (see attachment). IMHO it looks very nice.. They use buttons-filters instead of tabs...

poy (poy) wrote :

just as a note, we already have bug 344561 about this...

eMTee (realprogger) wrote :

The merge process is started with adding 'Keep finished files in the queue' function...

Changed in dcplusplus:
status: New → In Progress
Fredrik Ullner (ullner) on 2013-08-10
Changed in dcplusplus:
importance: Undecided → Wishlist
Fredrik Ullner (ullner) on 2013-11-30
Changed in dcplusplus:
status: In Progress → Confirmed
Fredrik Ullner (ullner) on 2013-11-30
tags: added: win32-ui
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers