I really like amarok, and it is a testament to its polish that my problems are so minor, but there are a few little annoyances with the 1.4 tree (I have not actually checked out and compiled the 2 version, so these may have been fixed).

Essentially, I am a bit unsatisfied with the way the collection browser sorts.  The ability to choose which tags to sort by is fantastic, but for control freaks like me it would be nice to have a way to customise the sorting method itself.

I have two issues:

1.  For each tag type, it would be nice to have a customisable list of words to ignore.  It is probably not in enough demand to merit a whole new tab on the preferences dialogue, but a box for each of the sortable tags (the ones in the 'group by' drop down box) would be nice.  For my collection, I could then enter under composer "the; de; les; von" and have my collection come out with (for instance) "de Séverac, Déodat" under S and not D.

2.  For numbers, could the sorting switch to numerical ordering?  In pseudocode, we might have something like

Code: Select all


operator customSort (QString a, Qstring b) {
    int aIndex = find [0-9] in a;
    int bIndex;
    if (aIndex != npos && (bIndex = find [0-9] in b) != npos && aIndex != bIndex) return a < b; //lexicographically
   
    //tokenise at the digit boundaries:
    //a[initial] is a up to aIndex, a[number] is the number contained in the string, and a[final] is the end
    //eg. if a = "test123test123", then a[initial] = "test", a[number] = 123, and a[final] = "test123"
   
    if (a[initial] != b[inital]) return a < b; //lexicographically

    if (a[number] != b[number]) return a[number] < b[number]; //numerically

    return customSort(a[final], b[final]);  //recurse on the tails
}


This quite simple procedure would make things much more intuitive for me, and it is restrictive enough that it should never annoy people: the numerical bit never kicks in until we know all the letters before match.

In my collection, I have all sorts of incongruities, like

- Mahler, Gustav
  | Symphony 1
  | Symphony 10
  |-Symphony 2

and

- Beethoven, Ludwig van
  | ...
  | String Quartet op. 135 in F Major
  |-String Quartet op. 18, No. 1 in F Major

The suggestion would fix this.

It would be easy to get this working, but getting it accepted by the main devs is harder.  I used to keep a custom version of amarok patched to fit my needs with a couple of minor fixes, but no-one would ever use my code, and it was a pain to merge the changes for new versions of amarok, so I have stopped doing this now.

If no-one else here is interested in this, I will live with it as it is, but it will only take a couple of files and a few lines of code to merge this in if people like the idea.

I'm pretty sure the collection browser is just ordered by the database backend. So like there's no place we could put your pseudocode really.

I have actually made this into a working patch for 1.4.8, but there is a freeze at the moment, so there is no point doing much with it.  When I get around to having a KDE4 build environment, I will fix this into the 2.0 branch and post the patch.

The backend sends the data to a KListView, which is sorted in collectionbrowser.cpp, so the presentation is certainly controlled by the application.

Cool, thanks!

This is now done on Bugzilla.

I noticed that there seems to be a general regression in many areas since 1.4 (though I can tell how much good work has gone into it of course), and particularly the collection browser.  For instance, you cannot browse by composer, or Genre/Artist/Album, etc.  I was wondering whether there was some planned dialogue for configuring this, or if the design is still open.  I would hesitate to make a new dialogue, since I know I am shocking at GUIs.

Many parts in 2.0 are, as you noted, indeed still unfinished. We welcome patches very much though! So, if you are able to fix/extend something, we'll be happy to include your patch.