Opened 11 years ago

Closed 7 years ago

#2762 closed Enhancement (wontfix)

web gui is missing progress/pieces display

Reported by: kim Owned by: kjg
Priority: Normal Milestone: None Set
Component: Web Client Version: 1.80
Severity: Normal Keywords: feature-disparity patch
Cc:

Description

I've written the code for this. Pretty picture attached. it only shows download progress not availability. That's left as an exercise to for the reader.

I won't submit the patches yet because it's also got some previous not-yet-accepted-patches in it (since they have accumulated) When those make it into head I can do the diffs more easily.

Attachments (6)

final_pieces_box.gif (40.7 KB) - added by kim 11 years ago.
screenshot of new feature.
transmission_patch_4 (38.9 KB) - added by kim 11 years ago.
patches for pieces box. ALSO includes compact view patches.
1to1pieces.diff (3.3 KB) - added by Longinus00 11 years ago.
chrome.png (5.6 KB) - added by kim 11 years ago.
ticket-2762-web-pieces-display.patch (16.2 KB) - added by wereHamster 11 years ago.
transmission_patch_4only_tidied (5.0 KB) - added by kim 11 years ago.
just patch 4 (original was patch3+4) with two unnecessary debug lines removed

Download all attachments as: .zip

Change History (18)

Changed 11 years ago by kim

screenshot of new feature.

Changed 11 years ago by kim

patches for pieces box. ALSO includes compact view patches.

comment:1 Changed 11 years ago by charles

  • Version changed from 1.76+ to 1.80

comment:2 Changed 11 years ago by Longinus00

I made a revision to your code so that the pieces display is 1:1 to the real pieces list. This will make the availability easier to display and be more meaningful. You might need to fuss around with the borders to make it pretty again but that's a minor detail.

Changed 11 years ago by Longinus00

comment:3 Changed 11 years ago by Longinus00

Due to my playing around with the code I have to advise against including it in transmission by default because trying to open the inspector for a torrent with millions of pieces will hang your browser. It was, however, still fun making my patch.

comment:4 Changed 11 years ago by kim

I did consider 1:1 but decided it was not appropriate because a) it can produce thousands of pieces which can't efficiently be displayed unless they are say a bitmap of 1 pixel each b) the current native version appears to be a fixed grid size (18x18). The code that does the n:1 mapping is a carefully designed algorithm that handles cases where there are less than m2 pieces (currently 182) and more than m2 pieces. It also handles having non-integral numbers of pieces per square neatly too. I haven't compared it to the native code but I expect they are similar (I wanted to do it myself from first principles for interest's sake). Having fun and learning is what it's all about :-)

comment:5 Changed 11 years ago by wereHamster

First, you need to attach your updated chrome.gif. Second, it looks like the attached patch contains code from #2758 (all the compact_mode stuff is not related to the progress/pieces display, is it?).

Changed 11 years ago by kim

comment:6 Changed 11 years ago by kim

chome.png attached. (Strange I did attach it before but the upload must gave aborted).

Yes the patch contains an unrelated/orthogonal patch - but I asked kjg about this before I added the patches (as I don't have a local revision control system for T set up). kjg said it was fine they could resolve that (esp given the other patch was intended to be included in mainline long ago....)

Changed 11 years ago by wereHamster

comment:7 Changed 11 years ago by wereHamster

kim, please check if I didn't forget anything. I had to do one small change: web/javascript/Makefile.am needed to be patched to install codec.js, otherwise the patch should be the exact same as yours, just without all the unrelated stuff from ticket #2758. The patch seems to work ok in my tests. And sorry about requesting chrome.png, it's not needed by this patch, it's only needed for #2758.

comment:8 Changed 11 years ago by kim

wereHamster, thanks for doing that. To check I ended up doing what you did but with normal diff, so for the record I attach my patch4only diff. I note one difference of import: my patches include an extra line in torrent.js which I think is still important (I haven't look at it in weeks). Not a bit of logic I appear to have been happy with but nevertheless I expect it should still be there: 60a61

this._last_checked_pieces = ""; bit of a hack

Also - without wanting to add confusion my attached patch omits two commented out debug lines (background-color:...) from common.css since they serve no purpose now.

Changed 11 years ago by kim

just patch 4 (original was patch3+4) with two unnecessary debug lines removed

comment:9 Changed 11 years ago by Longinus00

kim, have you tried your code with a torrent with a million+ pieces? I felt it was too slow in that case as I pointed out earlier.

comment:10 Changed 11 years ago by charles

  • Keywords feature-disparity patch added
  • Resolution set to invalid
  • Status changed from new to closed

IMO this is bloat for a web client.

comment:11 Changed 7 years ago by CrazyMonster

  • Resolution invalid deleted
  • Status changed from closed to reopened

IMO this is not... I find it quite useful to see what pieces I'm missing and whether I just have to wait and whether there's nobody that has that particular piece. And even if it is bloat, there's an implementation here that was ready to be merged, why don't merge it and leave it to the user to choose if enable it or not (with a client-side setting maybe)? As to the problem with torrents that have a massive number of pieces it should be possible to process them in a JavaScript? Worker, to keep the UI responding, but there still could be memory issues if the number of pieces is really high (I don't know how bad they would be, I think I'll do some experimentation in the next few days).

comment:12 Changed 7 years ago by livings124

  • Resolution set to wontfix
  • Status changed from reopened to closed

The patch is four years old and still has the same bugs. This is still bloat, and needing a client-side setting further shows that.

Note: See TracTickets for help on using tickets.