Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 41734 - Better progress indication should be provided where possible
Better progress indication should be provided where possible
Status: NEW
Product: obsolete
Classification: Unclassified
Component: vcscore
4.x
PC All
: P3 (vote)
: TBD
Assigned To: issues@obsolete
issues@obsolete
perfaudit perfuiresp perfpromod
: PERFORMANCE
Depends on: 50356
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-06 12:14 UTC by Antonin Nebuzelsky
Modified: 2006-12-04 21:20 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antonin Nebuzelsky 2004-04-06 12:14:07 UTC
CVS commands use a nice progress indication with
"a square moving from left to right and back"
which clearly let's the user know that the command
is executing and not finished yet.

This is helpful, but in many cases more
information could be provided.

For example Add recursively or Commit on a folder
can show a precise progress indication of how many
files and folders were processes out of the total
amount of files and folders.
Comment 1 Martin Entlicher 2004-04-06 12:45:15 UTC
This is just about percieved performance, not real performance.

To fix that, one would have to add some engine for each command, that
would parse it's output and update the progress bar accordingly. This
is possible (for recursive commands or commands that process more then
one file, it does not have sense for commands processing one file),
but from the implementation point of view this is a time-consuming
task (to do that for all VCS commands). Also, this can make the real
performance only worse.

All pros and cons need to be evaluated, I'm not convinced that this
should be implemented in promotion D.
Comment 2 _ rkubacki 2004-12-13 15:44:45 UTC
Sad, pretty sad. Of course that it is all about perception. That's
exactly why we do show splash during startup although it does not make
the start faster. It directly affects usability as the users will
refuse to use product that is not responsive.
Comment 3 pholthuizen 2005-09-17 20:24:25 UTC
Hi,

I am in favor of a real progress bar wherever possible. In my opinion a progress
bar gives the end user the impression that an automated task goes faster, even
if the implementation of the progress bar actually increases the total task
duration up to ±10%. The other progress bar has just the same function as an
hour glass cursor.

If the exact implementation of a specific bar is too resource intensive it is
always better to implement a less exact bar than no bar at all.

For example (just hypothetical):
If you need to check in 100 files and you want a very exact progress bar, you
need to know a lot of things, like file sizes, network performance, and so on to
make an precise indication. But maybe it is also enough to couple it to the
number of files. This may result in a bumpy progress bar, but nevertheless it'll
be better than none at all.

Sincerely,
Patrick Holthuizen


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo