Toolbar Request/Idea

[Thomas Lübking]

Am Wednesday 17 February 2010 schrieben Sie:
> > -> so far UNADDRESSED ISSUE:
> > interactive elements as a stop button. are they required?
> 
> Yes, they are definitely required. Some jobs could hang, or take a lot
> longer than the user thought.
Ok, this in combination with NHN's compound remark makes this pretty tricky, 
as we need to provide
a) interactive elements, not colliding with the std. items
b) a HOOK to a LIST of separate jobs
this can NOT (simply) be the same as the user might wish to click the list 
hook, the second job ends and the click goes to the cancel button :-(

> Some operations will be rapidly updating their progress text, example,
> a transfer operation.
err.. this is a bug.
If things are expected to update faster than the user could notice (like CLI 
output) they should be reduced. (as the user cannot make anything out of them 
anyway, you can still provide a log)

In your example the text should just be "Syncing iPod: nn%", the current track 
be the tooltip (iff at all, and not updating while shown)

The growing progress won't cause epileptics, as it's a predicted and 
continuous change (virtually any progressbar can grow rapidly fast)
 
> 1) Looks very busy
yupp, remove the italics and the fade ;-P

> sometimes the user wants to bring the background operation to the
> "foreground" of his attention.
                     ^^^^^^^^^^^^^
That's a user internal thing (like you can focus your wallpaper through a 
translucent window)
The problem is more to bring it to foreground for _action_ and that means, we 
MUST have reserved areas for status interaction.... :-\

As for inline multiprogress, think of bt chunks, i.e. we start 3 progressbars 
next to each other (but with only one label)
Another problem might be "logging", that is "when to hide wich job"

Need to rethink :D
 
Cheers