Community
Participate
Working Groups
After selecting a large directory (i.e. one with many nested sub-directories) in the 'Import projects' wizard, all controls are disabled while scanning the entered directory. Though the standard abort button appears in the lower-right corner of the dialog, the operation does not report progress. Neither a progress bar appears nor a message informs what is going on (e.g. 'Scanning directory foo...'). In its current state the dialog may well appear as if it was getting stuck in the process of finding projects. The 'Import existing projects' wizard, for example, also searches for projects while providing a progress bar and showing which directory is currently scanned. I suggest adapting the technique used there to give users feedback while scanning for projects.
Rüdiger, great proposal. Can you provide a Gerrit review?
In current 4.13 the progress bar is still not progressing but the label above indicates progress. Due to the problems of showing progress for directory traversal I think the progress bar should be removed (but the cancel button obtained) or set to indeterminate progress. In "Import existing projects" wizard the progress bar is changing but also not for the directory traversal part.
(In reply to Paul Pazderski from comment #2) > Due to the problems of showing progress for directory traversal > Can SubMonitor help with this problem?
(In reply to Alexander Fedorov from comment #3) > (In reply to Paul Pazderski from comment #2) > > > Due to the problems of showing progress for directory traversal > > > > Can SubMonitor help with this problem? Not really. The problem is that you don't know how many files/directories to check. So the tricks I know are: 1. count the files before starting (e.g. what Windows does before copy). Not so good option since the counting may require similar time as the actual smart import. 2. show some progress without knowing the end. Not so good because the progress must get slower towards the bar ending and the user still not really now when it finish. 3. show the user that we do not know the end by using an indeterminate progress bar
(In reply to Paul Pazderski from comment #4) > (In reply to Alexander Fedorov from comment #3) > > (In reply to Paul Pazderski from comment #2) > > > > > Due to the problems of showing progress for directory traversal > > > > > > > Can SubMonitor help with this problem? > > Not really. The problem is that you don't know how many files/directories to > check. So the tricks I know are: > 1. count the files before starting (e.g. what Windows does before copy). Not > so good option since the counting may require similar time as the actual > smart import. > 2. show some progress without knowing the end. Not so good because the > progress must get slower towards the bar ending and the user still not > really now when it finish. > 3. show the user that we do not know the end by using an indeterminate > progress bar I understand the problem. AFAIK SubMonitor supports the "hierarchical" structures and you do not need to build flat list of "things to process" first. Let's say you have N subdirs to check on first level=> Yua are starting SubMonitor with 100 units, and you use 100/N units for each subdir. And then you repeat this recursively. It will not look precisely, but IMO better than infinite one.
Which should bring the result I tried to explain as second variant. IMO both (2 and 3) have some pros and cons and I would probably accept a patch for both.
(In reply to Paul Pazderski from comment #6) > Which should bring the result I tried to explain as second variant. IMO both > (2 and 3) have some pros and cons and I would probably accept a patch for > both. Ah, yes. I was disoriented a bit by "user still not really know when it finish". TBH user never really knows *when* it finish, as we do not provide any ETA. From this point it will be a question of proper task label updates.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
