View Issue Details

IDProjectCategoryView StatusLast Update
0001950gnunet-gtkgnunet-fs-gtkpublic2012-02-28 10:06
ReporterChristian Grothoff Assigned ToChristian Grothoff Due Date
PrioritylowSeverityfeatureReproducibilityN/A
Status closedResolutionopen 
Product Version0.9.0 
Target Version0.9.2Fixed in Version0.9.2 
Summary0001950: show 'progress' dialog / window during directory scan for publishing
DescriptionFor large directories, it can take a while for GNUnet to extract the meta data and scan the file structure. Instead of just blocking everything for 5 minutes without warning, we should display some kind of progress dialog with a progress bar indicating that we ARE in fact doing something.
TagsNo tags attached.

Relationships

child of 0001966 closedLRN GUI master-issue 

Activities

LRN

2011-12-23 12:48

reporter   ~0005175

AFAIU, this requires certain APIs to be re-made in interator style:
You create an object that stores the function's internal state, then start the function. It should do some work, getting to the next element, then save its state and schedule itself to be called again, and exit. The scheduler will process its queue, then run the scheduled function, which will continue its work, and then schedule itself again. It will do so, until it's finished.
Before scheduling itself, the function will do a callback to check whether the original caller is still interested in its progress, this is used by the caller to be able to cancel the process, and to pulse the progress bar. That callback is also called (with an appropriate argument) to tell the caller that function is finished.
The manner in which the function schedules itself may vary, which is why IT does the scheduling, not the caller, so, for example, the function might just schedule itself to be called again at the end of the queue, OR it might encounter a blocking I/O, and tell the scheduler to call it (or one of its helper callbacks) again once the I/O can be done [partially] without blocking.

Christian Grothoff

2011-12-23 12:59

manager   ~0005178

Yes, you're totally right. This is why it has not been done yet ;-).

LRN

2012-01-16 12:35

reporter   ~0005261

Fixed between r19139 and r19157

Issue History

Date ModifiedUsernameFieldChange
2011-11-22 19:31Christian GrothoffNew Issue
2011-11-22 19:38Christian GrothoffPrioritynormal => low
2011-11-22 19:38Christian GrothoffStatusnew => confirmed
2011-11-26 17:23Christian GrothoffRelationship addedchild of 0001966
2011-12-23 12:48LRNNote Added: 0005175
2011-12-23 12:59Christian GrothoffNote Added: 0005178
2012-01-16 12:35LRNNote Added: 0005261
2012-01-16 12:36LRNStatusconfirmed => resolved
2012-01-16 21:06Christian GrothoffProduct VersionGit master => 0.9.0
2012-01-16 21:06Christian GrothoffFixed in Version => 0.9.2
2012-01-16 21:06Christian GrothoffTarget Version => 0.9.2
2012-02-12 20:25Christian GrothoffAssigned To => Christian Grothoff
2012-02-28 10:06Christian GrothoffStatusresolved => closed