New experimental toolbar by Thomas Luebking

[Thomas Lübking]

So may points... ;-)

Basically your suggestion covers rather an alternate playlist than a player 
toolbar.
Be aware that this does not provide current paylist editing abilities, so it 
could not be a replacement.
For a player toolbar, your approach lacks (dramatically ;-) skip fwd/bwd 
buttons (or whatever)

As for netbook design in general:
--------------
Width is not so much the critical limitation but rather height (16:9), i.e. 
there should be enough space to have collection, playlist and even context 
next to each other.

As for the handhelds (vertical layout):
----------
Iirc, it was concluded (at least i was told so) that a generally different UI 
would be required (i guess mainly to get the database and the playlist 
together) so this is not addressed. (For very compact solutions, I still 
prefer a "4D" approach.*)

As for a "wheel" in the toolbar:
------
First off - you can already drag the tracks to skip fwd/bwd. :)
(We need a better way to sell this to the user, though)

Visually**, the wheel model fails unless we can access more songs from the 
playlist what's a bit tricky regarding the (esp. random) navigators.
We'd basically need to redesign them to provide _one_ list, incorporating the 
queue etc. (what would then be a problem regarding infinite dynamic 
playlists.... gaaaahh =)

Another problem is that a believable*** wheel look would require to bend the 
fontshape alot, impacting the readability... and even horizontal squeezing has 
just been denied :-(
(+ technically there's nearby no "acceptable" way to do this except using 
OpenGL.
Using glyph painterpaths (for the transitions) is rather expensive, esp. as Qt 
will also invoke the rasterengine and conversions to gain antialiasing)

Thomas

* for a demo see here:
http://gitorious.org/qt4-gadgets/coolbar
(you'll need Qt 4.6)

**Not to talk about gradients and shadows which might interfere with the 
general UI style light model...

*** hmmm.. we may could play with shadowing borders to sell the 3D aspect, 
though...


Am Monday 01 February 2010 schrieb Lukas:
> What about starting to think about prev/current/next tracks not as
> buttons, but more as an items on a wheel.
> 
> Similar aproach is used in web
> http://www.javascriptkit.com/script/script2/spinmenu.shtml but in
> Amarok only 3 tracks would be displayed, as in amarok-touch-real.jpg
> (attachment). To create an impression of wheel shape
> amarok-touch-impression.jpg (attachemnt) the track in a middle has
> font size of ~130% compared to left and right ones and all 3 tracks
> has top alignment. The Currently playing track is bold.
> 
> To start playing selected track, click/tap it. To spin a wheel
> (toolbar could navigate trough entire playlist, if needed) , use mouse
> wheel, or if possible do a drag with finger (similar like in iphone
> navigating contacts) and then tap a song to play it.
> 
> amarok-touch-spin.jpg (attachemnt) displays case, when 2 previous
> tracks is displayed (single drag to left done). Currently playing
> track is still bold to give better feedback of whats going on.
> 
> The beauty comes then used in netbooks or smartphones where space is
> quite expensive, as such spinning could partially replace playlist
> GUI. It would allow changing tracks in playlist while having
> collection GUI taking full width. And this is done without any damage
> to 'native' desktop usage.
> 
> Of course some slight animations/hover effects would be nice too :)
> 
> Another case, that is not covered by any mockups previously is when
> window width is too narrow (same mobile device case) to fit all 3
> titles (prev/current/next). Using wheel, previous track could be
> hidden, leaving more space to other at the same time allowing user to
> access it with drag/mouse wheel to the left.
> 
> On 1 February 2010 00:46, Thomas Lübking <thomas.luebking at web.de> wrote:
> > Am Sunday 31 January 2010 schrieb John Atkinson:
> >> If not looking like a button destroys the visual stylings, then its
> >>  function could be to open the track/tag editor dialog for the current
> >>  track. FWIW, Winamp has similar functionality, although I believe that
> >> is double-click.
> >
> > Yes, but the point it that it must not look like a button in case we do
> > not absolutely rule out the "slide-to-change" feature... :-\
> >
> > _______________________________________________
> > Amarok-devel mailing list
> > Amarok-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/amarok-devel
>