Toolbar Request/Idea

Thomas Lübking thomas.luebking at web.de
Wed Feb 17 15:47:34 CET 2010


Hi everybody and Casey ;-)

1st off: i'm all for getting rid of the statusbar.
Now on getting the stuff up in the toolbar.

1) we cannot throw interactive elements under the pointer, i.e. in case 
they're required (iirc the collection scanner has a nice little "x" to stop - 
yesno?) we need to reserve an area for them.

2) we cannot take interaction from the user at all, i.e. at least when the 
cursor enters the toolbar, the standard stuff must be available

3) replacing the normal content (unless) hover could lead to the impression 
that the UI is locked (despite the background job)

4) some actions (collection scan) can last _really_ long, so the display 
should not be too intese/invasive

Attached is a sketch, but (in case of interest) i'll implement a dummy demo to 
really illustrate the below later on.

Behaviour:
------------
New statusaction is added:
-> tracklabels & skip icons will be replaced*
-> progressbar + status label in the background.

after a few seconds or on enter events:
--> foreground replacement will be reverted 
--> background info remains (+ a tooltip on the toolbar)

*UNLESS the pointer is currently above the toolbar. then we wait for the leave 
event.

This does not take away the normal UI at all and also resembles the background 
job nature.
Don't mind the visibility* - if there're screen updates (counter/bar) the user 
will notice =)

*To support bg label readability, we'll temporarily remove boldness, opacity 
and animation from the current track.

Actually this makes a step away from static UIs and towards the 4th gen 
toolbar i started to play on, but i guess we can find an evolutionary step 
between :)

-> so far UNADDRESSED ISSUE:
interactive elements as a stop button. are they required?

Cheers,
Thomas

Am Wednesday 17 February 2010 schrieb Casey Link:
> Hey Thomas (and the rest of amarok-devel),
> 
> Some devs were discussing in IRC the ugly state of the current Status
> Bar (particularly the Progress Bar).  We wanted to get your opinion
> regarding an idea we had.
> 
> Note: Progress Bar in this email refers to the bar(s) at the _bottom_
> of the window that show progress operations.
> 
> The proposed solution is to eventually axe the status bar, and move
> its information elsewhere. We were brainstorming and decided a good
> place for a _primary_ progress bar would be the toolbar. I hate to
> bring this up now, because you're working so hard on making the
> toolbar awesome, but can you envision a toolbar design that could
> display this information?
> 
> Examples of operations that will be displayed:
> * Copying/Syncing tracks to media Devices
> * Full Collection Scans
> * Service Operations (e.g., downloading the Jamendo database)
> 
> Only one operation would be displayed at a time, if there are multiple
> concurrent operations something like "Multiple background tasks" with
> a combined progress meter would be displayed.
> 
> Regards,
> Casey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: amarok-statusbar.jpeg
Type: image/jpeg
Size: 116239 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20100217/436c42c6/attachment-0001.jpeg 


More information about the Amarok-devel mailing list