Bug 173894 - Possibility to move start, stop buttons and progressbar below playlist
Summary: Possibility to move start, stop buttons and progressbar below playlist
Status: RESOLVED INTENTIONAL
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-30 11:58 UTC by David Krapohl
Modified: 2009-02-28 23:06 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description David Krapohl 2008-10-30 11:58:04 UTC 
Version:            (using KDE 4.1.2)
Compiler:          gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 
OS:                Linux
Installed from:    Compiled From Sources

It would be nice to be able to move volume slider, the progressbar including start, stop, forward and rewind buttons to the bottom of Amarok's main window as it used to be in Amarok 1.x versions. 
It could be done like in dolphin where it is possible to move sidebars and konsole plugin to different places.
Comment 1 Jordi Polo 2008-11-30 13:29:17 UTC 
moved to Amarok
Comment 2 Michael Pyne 2009-02-28 20:41:43 UTC 
I was about to close this as WORKSFORME until I realized it was reported against JuK and not Amarok by accident.
Comment 3 Mark Kretschmann 2009-02-28 20:57:04 UTC 
Thanks Michael :)

Anyway, from our side that's pretty much a WONTFIX too. We have no plans to implement this kind of configurability for now.

I won't discuss our reasons for it right now, but if the reporter would like to see that, we could provide more info.
Comment 4 David Krapohl 2009-02-28 22:18:16 UTC 
Naa, thanks. I didn't expect it to happen. But thanks for the tip with juk, though.
And sorry for the confusion with juk and amarok.
Comment 5 Dan Leinir Turthra Jensen 2009-02-28 23:06:32 UTC 
What Markey is saying isn't entirely true - the way it is suggested in this report is, in fact, exactly what would end up happening when we unlock the application layout as we discussed last week :) The report resolution should thus probably be RESOLVED LATER (iirc that's the correct resolution for something that isn't going to be implemented this moment but will later)