Enhancement: hierarchical file list

[GoogleCodeExporter]

Could the file list be made into a hierarchical tree view? This is essential 
for very large torrents-- not only to make the file list more manageable, but 
also to ease changing the priorities of multiple related files together.

If this feature is implemented, don't forget some way to expand/collapse all 
folders at once! The lack of this feature is actually what makes the official 
Transmission Qt client unsuitable for me, as the file view starts completely 
expanded and it would take ages to manually collapse all 1000+ subfolders in 
some of the torrents I use.

Original issue reported on code.google.com by gardne...@gmail.com on 2 Jan 2012 at 11:21

[GoogleCodeExporter]

It had already been made into a hierarchical view when you opened the ticket, 
but the selection features you mention were lacking.

I'd been putting it off because of the increasing overlap of the torrent add 
dialog and the files tree view. Duplicate code needed merging and the behavior 
needed to be more consistent, so I've just done that.

It's committed, almost complete. There's an issue with preferences not being 
propogated upwards correctly which I'll fix.

Original comment by a...@eth0.org.uk on 4 Jan 2012 at 11:57

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Should be fixed now.

Original comment by a...@eth0.org.uk on 4 Jan 2012 at 4:56

• Changed state: Fixed

[GoogleCodeExporter]

Ah, guess I should have tried trunk before creating a ticket for the feature. I 
just tried it, and the hierarchical file tree works very well, including the 
way it collapses all subfolders when you collapse a parent.

However, torrents with large number of files now cause a huge spike in CPU 
usage when you select them, with a sometimes very noticeable pause before the 
GUI becomes responsive again. The worst case in my testing was a torrent with 
5000+ subfolders in a relatively flat hierarchy, which caused 
transmission-remote-gtk to hang for  20 minutes on my Macbook (2.0GHz Core 2 
Duo).

Original comment by gardne...@gmail.com on 4 Jan 2012 at 10:37

[GoogleCodeExporter]

Ouch, that's not good. I'll have a think and see what I can do sometime.

Is there a noticible freeze if you open that torrent using the torrent add 
dialog? I can understand why the main files tree view is slow doing large flat 
directories - the inserts are done in a bit of a lazy way, just searching over 
each level for each file until it finds its parent. This is partly because I 
wasn't sure if there's any guarantees about order. There's definitely 
optimisation I can do, though.

The .torrent files get parsed into a convenient tree before inserting into the 
GtkTreeModel. Building the tree uses a similar algorithm, but I'd be interested 
to see how doing that on simple data structures instead of the GtkTreeModel 
compares.

I don't have any torrents like yours to test with. Would it be possible to send 
me that 5000 one via email?

Original comment by a...@eth0.org.uk on 5 Jan 2012 at 8:33

[GoogleCodeExporter]

There's still a noticeable freeze with the torrent add dialog, but it's only a 
couple minutes for the 5000+ torrent.

If a more efficient algorithm would be possible given some particular ordering, 
what about just sorting the data before building the tree? That amount of data 
should be nothing to an O(n log n) algorithm like mergesort.

I've also emailed you a link to that torrent, for testing.

Original comment by gardne...@gmail.com on 5 Jan 2012 at 9:45

[GoogleCodeExporter]

Thanks, I'll try to apply a similar solution (whatever that is) to both the 
torrent add and regular file model. It's the same crappy algorithm in the add 
dialog, just less code/complexity which gets run by it.

I did think about sorting before inserting, the problem is that the ordinal 
position of the file in the elements array is important. It's saved as a column 
in the model, because it's required when sending enabled/priority changes to 
Transmission.

Transmission seems to just send the order it parsed out of the torrent file - 
which is always in order as far as I've seen, but I think that's because of the 
creating app and therefore not guaranteed.

My idea right now is to maintain a stack of references to parents and their 
names, for the last insertion. I'm fairly sure this will work well, just 
thinking about it. It should be able to recall the parent without searching 
(just a few strcmp) if it hasn't changed, and if it has will only need to 
search the levels necessary.

Unfortunately magnet links complicate this a little, as magnet torrents can 
suddenly appear with new files, but it shouldn't be too much of a problem.

Original comment by a...@eth0.org.uk on 5 Jan 2012 at 3:52

[GoogleCodeExporter]

The changes I pushed recently completely fix this for the torrent add dialog, 
which builds up its own tree first. Checking the previous addition instead of 
searching seems very fast with that torrent you gave me.

Unfortunately the main files one still needs work. I did try to do something 
like the above for this too - using the GTK model but it turned out horribly 
slow. Maybe building up a tree first is the fastest way.

A relatively simple change to the update parent sizes code has made it much 
faster, though.

Original comment by a...@eth0.org.uk on 8 Jan 2012 at 11:27

[GoogleCodeExporter]

Hi,

Give it a try and let me know. Both tree views work quickly for me now. 

Original comment by a...@eth0.org.uk on 9 Jan 2012 at 9:55

[GoogleCodeExporter]

There's now only a 1-second delay when selecting that large torrent in the main 
torrent list, which is a vast improvement over the multi-minute delays I was 
getting before. (I should mention that I'm on a much faster connection to the 
transmission-daemon than I was on before; with this connection the previous SVN 
head was giving me 3-minute hangs instead of the 20-minute hangs I was getting 
on a slow internet connection. I no longer have that slow connection to test 
on, unfortunately.)

Thanks for the improvements! Any idea when you'll be cutting a new release?

Original comment by gardne...@gmail.com on 10 Jan 2012 at 11:17

[GoogleCodeExporter]

Thanks for the feedback.

Unfortunately a torrent with that many directories in any given level 
potentially has a lot of iterations to do for every entry under it. It's 
because it needs to check them to figure out the priority of the parent (ie. 
mixed or fully changed). Using simple data structures before putting it in GTK 
has made this much faster, though.

Anyhow, I've just done one more optimisation and I'm happy with the performance 
now. Taking advantage of the tree not being glib/gtk anymore, it now uses a 
thread to build that tree only if there's more than 600 files.

Not sure if it's faster, but it feels faster without the UI freeze.

Original comment by a...@eth0.org.uk on 11 Jan 2012 at 8:04