Amarok/Archives/2009SprintRoadmapandTODO

From KDE Community Wiki

This is a summary of the developer discussions and relevant plans that we made throughout the weekend. This is intended as an aid to developers who want to implement the features/changes that were discussed, so the items are split up by short/long term goals.

If you complete ANYTHING on this page, please MARK IT AS SUCH. This should reflect what is to be done, and otherwise we'll all just waste our time.

Features/Changes/Fixes to Implement

Short Term: for 2.1.0

Usability changes

  • Change node behaviour. Double click on any node with children will expand it.
  • Shrink text in PUD when there isn't enough room to show it.
  • Add a "Load Playlist" and "New Playlist" menu option under the Playlist menu
  • Play and Add do the same thing.....definitely remove. Play should definitely immediately start playing what is chosen
  • When tracks are added to the playlist, ALWAYS scroll to the newly added item to make it visible
  • Checkbox for On/Off of Dynamic Playlists: toggle button is really really undiscoverable
  • Experiment with making fadeout on stop shorter
  • Reset playlist search bar when playlist is modified or cleared

Short Term: for 2.1.1

Usability changes

  • When saving a playlist present the user with the option to override the last loaded playlist.
  • When clearing playlist ask if it wants to be saved (with a "do not ask again" option)
  • Playlist sidebar has a terrible QToolBox: Use same system as the Internet browser (done locally by nikolaj)
  • Label the playlist area.
  • Change "load playlist" to "load tracks"
  • Highlight/different color for visible applets in the toolbar
  • Selected applet in CV with fixed size is fixed, but flowing applets like lyrics/wiki/applet/etc expand to fill the rest of the CV. (done locally --leo)
  • Alignment of bottom of CV and playlist important
  • Show Context View checkbox in General Options
  • Add a PUD action to "insert as next" (or something)
  • Show info text if CV is empty (done in local branch --leo)

PlaylistBrowser

  • NEED TO FIX the duplicates on playlist scanning for 2.1!!!!!

Meta/Collection

  • the ::as< Capability > () function returns a pointer that the caller is then responsible for---introduces plenty of memleaks....
    • rename the function to ::create< T > (done locally --leo)
  • Meta::Track::uidUrl -> Meta::Track::permanentUrl
  • Make rating an enum { NotRated, Unratable, 0-10 }

Script API

  • Dbus function for setting the theme- JUST FOR DEBUG atm
  • be able to run a script interactively in the script console. would be easy.

Misc

  • context menu items showing up in PUD when dragging from playlist need cleaning
  • We need a visual indicator when dynamic playlists are enabled. [DONE in local branch ---leo]

Medium Term (2.2 for sure)

Usability changes

  • Improved queue concept
  • Favor in Playlists menu should really be a dynamic playlist bias not its own menu option---clutter.
  • Do a user survey about use-cases of Amarok

PlaylistBrowser

  • Proper fix for duplicate-playlist-on-scan issue is to synchronize the playlist in the db with the playlist file on disk--- write in either one results in both getting updated.

Meta/Collection

  • Use stack-allocated objects that forward method calls instead of KSharedPtr. why? crash less, less potential for abuse. about a weekend or two of work, not hard, just has to get done. will make it much easier to use in the future, idiot-proof it.
  • Write a base implementation of Meta::Track with very simple basic functions? Just storing the simplest data for example. Currently the same simple implementation is copied and re--implemented in a lot of places.
  • Switch everything to ms from s, and qint64. Mark has a branch for that, will try to get it done for 2.2.
  • Remove Meta::Track::lessThan, it does NOT belong there. put it somewhere else.

Script API

  • Notification that a script is closing, so a scriptClosing() signal of some sort
  • FOOD FOR THOUGHT: For debug/some scripts---load a new svg theme file. Themes as scripts. A few lines of code that just loads a new svg file.However, then people will be using scripts to load themes, doesn't make sense in the Script Manager. Don't go halfway...
  • WHY DO WE NEED TO RESTART THE SCRIPTMANAGER!?!>?!?
  • Handling script exceptions (marking them a crashed in the scriptmanager)
  • Scripts need to be translated. They need scripty. So, scripts w/ i18n NEED TO LIVE IN KDE SVN. Then we can have scripty extract the messages and load them on demand. Note: Step has a python script which parses a text file and creates a file that scripty can handle and translate.
    • We could offer to host scripts (as we do now) and get the translations involved. Directly contact the popular scripts and offer? TRANSLATIONS ARE IMPORTANT.
  • Save the debug output, and then if a script crashes pop up a box that shows the script BT or exceptions so the user can add that to a bugreport. (some) users are not going to restart amarok with -d and then crash the script and then grep the console output.
  • If there is an amarok URL opened for a script that is not installed, Amarok asks you if you want to install that script.

Context View

  • ContextView state machine (nothing/playing/browsing, define hierarchy)
    • Possibly allow editing of all states at the same time, without being in those states. Needs good UI.
    • Manual toggle from any state to Home (if not playing) or Current (if playing).

Long Term:

Script API

  • Could we have an abstract QueryMaker that covers all the collections, so we don't have to expose each collection-specific querymaker? That way script writers do not need to know anything about each collection or even what collections there are, but can simply ask for tracks/info/etc.

Meta/Collection

  • Multiple local collections.would be able to possibly throw away the file browser with the ability to define a temporary collection. maybe. would be able to have a different collection for an external drive, for example.
    • ONE COLLECTION TO RULE THEM:
      • have a meta-collection which contains all tracks from the various collections---the user doesn't care about where his tracks are, he just wants to play them. he wants to see the tracks and add them to the playlist.
      • would be really awesome. toggle in the collection browser between seeing all the collections and seeing the unified collection.
      • imagine searching for a track, and if you don't have any local ones you see which stores you can by the track from.
  • Amarok should KNOW about everything that you play. You should be able to rate *any* track, even a track that is not in your collection. Stick it in the DB somewhere. Single table, col w/ url, etc.

Misc

  • Big Browser Redesign:
    • Collection/Playlist/Services etc all fit under the same paradigm that that services currently use.
    • Header w/ breadcrumb to navigate back.
    • No more left vertical tabs---the whole left thing becomes one big left/"back" button.

UI Discussion and Plans

Bookmarks/Position markers - two types of bookmarks: how should they be named, where should they be integrated, can they be unified as one?

#1 take-away point: beauty as alignment.

  • Horizontal alignment is very important to perceive an app as pretty and coherent. Align things like the bottom of the playlist/CV/Browsers and even items across browsers if possible.
  • Work on alignment wherever we can. Look to see what can be lined up:
    • Short/Medium term:
      • Between browsers
      • Toolbars in browsers/playlist/contextview
      • Main toolbar redesign (nuno's mockups)


  • whole CV needs to react to what the user is doing in amarok
  • get rid of some of the 4 redundant places that show the name of the current song


  • 3->2 pane UI:
    • Collection | Playlist | CV
    • Vertical button between Playlist and CV which collapses the left edge of the CV to cover the whole playlist too. can press again to expand again
    • Possibly automatic covering of the playlist with the CV after a certain period of time...after a track starts playing. Requires guessing what the user wants. Needs to be configurable in the preferences to turn off automatic hiding/unhiding. On by default, can be disabled (if it is usable and nice).