Toolbar Request/Idea

[Bart Cerneels]

Indeed the "compoundedness" is important. And not trivial to
implement. So I propose we keep the current progressbar logic but just
change the UI to suite the toolbar.

I think we also need to consider the other, current and future,
toolbar implementations. So either themable (CSS?) widgets or
something "bland" enough to fit in any toolbar.

I must second that the watermark design is not a good idea.

P.S. aaaaaaaahhhhhhh, look what you are making me do top poster. It's
contagious ;).

On Wed, Feb 17, 2010 at 16:09, Nikolaj Hald Nielsen
<nhnfreespirit at gmail.com> wrote:
> 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
>>
>>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>