View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002522 | gnunet-gtk | gnunet-fs-gtk | public | 2012-08-26 06:39 | 2014-04-08 14:42 |
| Reporter | dad | Assigned To | Christian Grothoff | Due Date | |
| Priority | high | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Platform | linux | OS | Debian | OS Version | sid |
| Product Version | 0.9.3 | ||||
| Target Version | 0.10.1 | Fixed in Version | 0.10.1 | ||
| Summary | 0002522: Use a separate list for download in progress | ||||
| Description | Hello, When doing a search with dozen or more results, it can be hard to track state of current download. It could be interesting to use a dedicated list of current downloads. It may ease the re-publication of “verified” data, for example, I download a file, check it is really what it looks like and publish it under one of my namespaces. Combined with metadata and keyword editing before the re-publication, it will ease the use of namespaces as a kind of trust publications or could be looked like a system à-la re-twitt. Regards. | ||||
| Tags | No tags attached. | ||||
| I see that this might be nice, but I'm not 100% certain. What do others think? | |
| We could split the "*" tab into "downloads" and "publications" tabs. However, we'd also need to make items more...movable. The essence of this bug report is that items stay in search result list until that list is closed. For long-running searches it means that items will never be orphaned -> won't be moved. Thus maybe we need to redefine the process of moving items. Maybe move an item to the proposed "downloads" tab as soon as download starts? Or just put a duplicate of it? How difficult it will be to track duplicate items (item moving code looks complex to me)? | |
| Well, I think duplicating the item is likely at least as simple as moving it. We'll just have to keep two row references for each item (one of which may be NULL) and then update the tree models for both. I don't see that as particularly complex. Now, should the separate 'downloads' view be hierarchical (for directory downloads) or always flat? | |
| Hierarchical, obviously. Losing hierarchy for directory downloads doesn't sound like something i'd like to see. It will also make similarly-named files from two different directories undistinguishable in the 'downloads' view. Although, you could transform their display names by prepending parent directories to them, but that might be easier said than done (will probably have same problems as automatic name suggestion does). | |
| Implemented in SVN 32173. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-08-26 06:39 | dad | New Issue | |
| 2012-08-26 21:59 | Christian Grothoff | Note Added: 0006292 | |
| 2012-08-26 22:00 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2012-08-26 22:00 | Christian Grothoff | Status | new => feedback |
| 2012-08-26 22:00 | Christian Grothoff | Priority | normal => low |
| 2012-11-10 21:38 | Christian Grothoff | Relationship added | related to 0002621 |
| 2012-11-10 22:09 | LRN | Note Added: 0006565 | |
| 2013-07-10 21:48 | Christian Grothoff | Priority | low => normal |
| 2013-07-10 22:06 | Christian Grothoff | Priority | normal => high |
| 2013-07-10 22:06 | Christian Grothoff | Target Version | => 0.10.0 |
| 2013-07-10 22:07 | Christian Grothoff | Status | feedback => assigned |
| 2013-07-13 19:11 | Christian Grothoff | Target Version | 0.10.0 => 0.10.1 |
| 2013-07-14 18:24 | Christian Grothoff | Priority | high => normal |
| 2013-09-07 19:18 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2013-09-07 19:18 | Christian Grothoff | Status | assigned => confirmed |
| 2013-09-22 15:46 | Christian Grothoff | Target Version | 0.10.1 => 0.11.0pre66 |
| 2013-10-08 18:16 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2013-10-08 18:16 | Christian Grothoff | Status | confirmed => assigned |
| 2013-10-20 18:35 | Christian Grothoff | Target Version | 0.11.0pre66 => 0.10.1 |
| 2013-10-27 15:28 | Christian Grothoff | Note Added: 0007566 | |
| 2013-10-27 16:38 | LRN | Note Added: 0007567 | |
| 2013-11-20 12:17 | Christian Grothoff | Priority | normal => high |
| 2014-01-05 13:32 | Christian Grothoff | Target Version | 0.10.1 => 0.11.0pre66 |
| 2014-01-30 15:33 | Christian Grothoff | Target Version | 0.11.0pre66 => |
| 2014-02-03 21:07 | Christian Grothoff | Note Added: 0008056 | |
| 2014-02-03 21:07 | Christian Grothoff | Status | assigned => resolved |
| 2014-02-03 21:07 | Christian Grothoff | Resolution | open => fixed |
| 2014-02-03 21:07 | Christian Grothoff | Fixed in Version | => 0.10.1 |
| 2014-02-03 21:07 | Christian Grothoff | Target Version | => 0.10.1 |
| 2014-04-08 14:42 | Christian Grothoff | Status | resolved => closed |