Toolbar Request/Idea

[Nikolaj Hald Nielsen]

There are a few extra things that are needed. It is possible for many
jobs to run as well, and it should be possible to do what is currently
possible in the statusbar, namely expand a compound progress bar
(averaging the progress of all running jobs) to show the individual
jobs and be able to stop them individually.

That said, I really don't like the idea of showing progress
information as a "watermark" type thing, and especially not behind
completely unrelated elements. So far I have been against most
attempts to remove the statusbar, simply because as far as I am
concerned, no one has come up with a viable alternative for the
compound progress bar.

- Nikolaj

On Wed, Feb 17, 2010 at 3:47 PM, Thomas Lübking <thomas.luebking at web.de> wrote:
> 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
>
>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
>