Major download-treeview overhaul

Lantash: I strongly agree with all of that. Downloads cannot be sorted because of the queue nature of the download list, that's why the list header could be dropped. It wouldn't be hard to display a progress bar if and only if the download progress is greater than 0%. For non-active downloads, this is not often the case anyway. If both the ETAs and the download speed are included in the download list, we could even drop the "ETA-speed" bar. I don't like it anyway the way it is right now. A simple mockup would be highly useful for this blueprint.

Sander: Here is a (very crude) mock-up: http://dl.getdropbox.com/u/179818/LottaNZB/treeview_mockup.png
What should be changed in this mock-up:
(1) We should make the window not as wide as I showed in the mock-up
(2) We should add a progressbar where I put (progressbar)
(3) The current download should _always_ be on the top of the download queue (this way you can always find your download speed in the same place)
(4) We should use the Treeview rules hint
(5) The size of the current download should also be shown

Sander: After thinking about this a bit longer I came up with a couple of new ideas.

(1) There are people that like the treeview as it is. It's very clean. We should make the 'classic' treeview optional. This can perhaps be done by replacing the DownloadList class in gui.py by a plug-in. This way the _cell_data_text_func method or whatever can render anything you would like it to.
(2) Plugins should be able to render data the way they like it. How can we do this? Well, in the following way. Every plugin should have a method that gets a list of downloads as an argument. This method renders the types that this plugin provides. For instance the TV Series plugin will render upcoming tv shows. The method returns the list of downloads that have not been rendered yet. After this, the standard gui renderer will render the downloads that have not been rendered yet.
(3) Instead of rendering as in (2), we can also let this function set a specific "text" for every type. This way, it's possible to create a standard one-renderer-fits-all method in gui.py. This renderer would just render the text. Example: plugin returns "<b>Title of Series</b> \n blablablablabla". This is rendered by gui.py. This text-variable could even be a tuple. This way it can return: ("<b>Title of Series</b> \n blablablablabla",42) where 42 is the percentage the progressbar would show.

Well, this may be a bit messy, but I think that point (3) would prove to be a viable solution to this overhaul problem..