I know I'm late to the discussion, but I thought I'd share features of
my own design of MaClientProcess, which has been part of the Maui
framework for Squeak since 2004, how it handles progress.  It is based
on the ultimate progress-bar handling I did in VisualAge and published
in 1997:

  - The ClientProcess runs in the background, of course.
  - It's UI can be placed anywhere on the desktop, or minimized.
  - Shows time elapsed and estimated time remaining.
  - Shows units processed as a fraction of total units.
  - Allows descriptions of sub-tasks being worked on to be displayed.
  - Doesn't appear at all unless the task takes more than 5 seconds to
complete, that way the system is not presenting progress bar and then
immediately removing it.
  - Allows the user to PAUSE or change the priority of the Process --
generically without client code knowing anything about that.
  - No nesting.
  - UI updates based on a time-interval rather than client processing
so that performance is NOT affected.




On Thu, May 31, 2012 at 6:58 PM, Igor Stasenko <siguc...@gmail.com> wrote:
> If you would ask me (yeah nobody asking me, by i will tell anyways ;) )
> how the indication of a progress of some process should look like,
> here's my potential answer:
>
>
> - a tiny one line in a corner of desktop (instead of huge banner
> centered in window,
>  sticking on top of everything and obscuring the view)
> - not blocking user input
> - no stupid nesting.. i don't care what happens inside of something
> else happens..
> if it is really necessary, i would just replace the title of a task
> with it's subtask title while it performing.
> this is just about first rule: it has to be a single line, not a bunch
> of lines stocking one over another..
> i think this is abuse.
>
> most of the times, i just need a notion of progress of a whole thing,
> not progress of it's subthings
> (if user really wants, he can hover the mouse over progress line to
> see the details, but by default
> it should take minimal space on the screen).
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Reply via email to