Jordan Lee [Sat, 4 Feb 2012 01:28:15 +0000 (01:28 +0000)]
(trunk) #4732 "allow switching between internal and system libnatpmp" -- fixed with patch scarabeus and applied by me, so any patch breakage is probably mine... ;)
Jordan Lee [Fri, 3 Feb 2012 17:12:17 +0000 (17:12 +0000)]
(trunk gtk) To improve translations, help gettext to differentiate between the gerund and verb forms of some -ing words like "Seeding" and "Downloading" -- fixed.
I wasn't sure how to do this, so for the benefit of my future self or anyone else who's interested, here are some breadcrumbs I found: https://trac.transmissionbt.com/ticket/4717#comment:6
On Lion with group rows shown, when moving torrents to a group row that did not previously exist, do sliding instead of fading and keep selected torrents selected.
Jordan Lee [Fri, 13 Jan 2012 22:10:26 +0000 (22:10 +0000)]
Silence a minor compiler warning.
We used to pass no button text + response_id pairs when creating the dialog because only gtk_dialog_add_button() would return back the actual button widget s.t. we could use a grab on it. However as of GTK+ 2.20 we can use gtk_dialog_get_widget_for_response() to get the button, so we can create dialogs in the more common way (which also fixes the gcc warning)
Animate rearranging the queue separately from the main filter animation. This allows us to ensure that the animation shows the dragged torrents being moved instead of the torrents around them.
#4696 Step one of getting the main table to animate for everything besides the already-added sorting. This also contains improvements to the sorting code by sorting in-place.
#4694 Don't call reloadData on the main table on each updateUI call (and each sort) if the order hasn't changed; instead call setNeedsDisplay:. Don't call reloadData when toggling the main window per-torrent status string
Jordan Lee [Sat, 31 Dec 2011 21:28:53 +0000 (21:28 +0000)]
(trunk libT) #4690 "getPeerCandidates() uses more CPU than necessary" -- fixed.
Once we've scored all n candidates, we sort them by score so that we can pick out the k best candidates. If n is large, sorting them can be expensive. If we use the Selection Algorithm, we select in O(n) without having to sort.
Jordan Lee [Thu, 22 Dec 2011 19:35:13 +0000 (19:35 +0000)]
(trunk libT) #4684 "tr_cpSizeWhenDone() is slow for huge torrents that we're only partially downloading" -- fixed.
There are actually two different implementations of the byte-counting in that function: a slower implementation was added prior to 2.40 in r12918 to double-check the standard implementation. This checking was added to help smoke out a bug that was fixed in r12920, but I forgot to remove that slower implementation.
Jordan Lee [Wed, 14 Dec 2011 05:58:23 +0000 (05:58 +0000)]
(trunk libT) #4666 "webseed downloading never gets downloaded" -- fixed.
The webseed in question is downloading from an ubuntuone.com url. We ask for piece-sized ranges in a couple of different concurrent connections, and curl hints to the server that it's okay to gzip the response, or deflate it, or leave it raw. It looks like there's a bug in the server or in libcurl (or, somehow, Transmission) that's not compressing or decompressing these responses correctly -- we never get the right number of bytes in the response from libcurl. If we ask for the contents uncompressed, the download progresses towards completion.
As an aside, when testing this I noticed that deluge is a lot faster than Transmission on this torrent. In order for Transmission to reach parity here, webseed.c needs to know when it's appropriate to have more than 4 concurrent tasks and/or be able to request ranges > the torrent's piece size.
Jordan Lee [Wed, 14 Dec 2011 05:44:15 +0000 (05:44 +0000)]
(trunk libT) fix a minor memory leak in the bencode regression tests.
Found by llvm's static analyzer. This is a minor issue since the leak is in an automated test rather than in shipping code, but it's still better to fix it.
Jordan Lee [Wed, 14 Dec 2011 05:42:15 +0000 (05:42 +0000)]
(trunk libT) fix warnings in fileset_get_empty_slot() found by llvm's static-build analyzer.
static-build found a potential NULL pointer dereference. The circumstances where this could get triggered don't seem very likely, but doesn't hurt to fix the warning.