View Issue Details

IDProjectCategoryView StatusLast Update
0002522gnunet-gtkgnunet-fs-gtkpublic2014-04-08 16:42
ReporterdadAssigned ToChristian Grothoff 
Status closedResolutionfixed 
PlatformlinuxOSDebianOS Versionsid
Product Version0.9.3 
Target Version0.10.1Fixed in Version0.10.1 
Summary0002522: Use a separate list for download in progress

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.

TagsNo tags attached.


related to 0002621 closedLRN Better Download dialog 


Christian Grothoff

2012-08-26 23:59

manager   ~0006292

I see that this might be nice, but I'm not 100% certain. What do others think?


2012-11-10 23:09

developer   ~0006565

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)?

Christian Grothoff

2013-10-27 16:28

manager   ~0007566

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?


2013-10-27 17:38

developer   ~0007567

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).

Christian Grothoff

2014-02-03 22:07

manager   ~0008056

Implemented in SVN 32173.

Issue History

Date Modified Username Field Change
2012-08-26 08:39 dad New Issue
2012-08-26 23:59 Christian Grothoff Note Added: 0006292
2012-08-27 00:00 Christian Grothoff Assigned To => Christian Grothoff
2012-08-27 00:00 Christian Grothoff Status new => feedback
2012-08-27 00:00 Christian Grothoff Priority normal => low
2012-11-10 22:38 Christian Grothoff Relationship added related to 0002621
2012-11-10 23:09 LRN Note Added: 0006565
2013-07-10 23:48 Christian Grothoff Priority low => normal
2013-07-11 00:06 Christian Grothoff Priority normal => high
2013-07-11 00:06 Christian Grothoff Target Version => 0.10.0
2013-07-11 00:07 Christian Grothoff Status feedback => assigned
2013-07-13 21:11 Christian Grothoff Target Version 0.10.0 => 0.10.1
2013-07-14 20:24 Christian Grothoff Priority high => normal
2013-09-07 21:18 Christian Grothoff Assigned To Christian Grothoff =>
2013-09-07 21:18 Christian Grothoff Status assigned => confirmed
2013-09-22 17:46 Christian Grothoff Target Version 0.10.1 => 0.11.0pre66
2013-10-08 20:16 Christian Grothoff Assigned To => Christian Grothoff
2013-10-08 20:16 Christian Grothoff Status confirmed => assigned
2013-10-20 20:35 Christian Grothoff Target Version 0.11.0pre66 => 0.10.1
2013-10-27 16:28 Christian Grothoff Note Added: 0007566
2013-10-27 17:38 LRN Note Added: 0007567
2013-11-20 13:17 Christian Grothoff Priority normal => high
2014-01-05 14:32 Christian Grothoff Target Version 0.10.1 => 0.11.0pre66
2014-01-30 16:33 Christian Grothoff Target Version 0.11.0pre66 =>
2014-02-03 22:07 Christian Grothoff Note Added: 0008056
2014-02-03 22:07 Christian Grothoff Status assigned => resolved
2014-02-03 22:07 Christian Grothoff Resolution open => fixed
2014-02-03 22:07 Christian Grothoff Fixed in Version => 0.10.1
2014-02-03 22:07 Christian Grothoff Target Version => 0.10.1
2014-04-08 16:42 Christian Grothoff Status resolved => closed