Amarok Blog

One handy feature of amaroK's dynamic mode, the complation of a custom combination of playlists, are currently obscured behind right-mouse-button menus.

A while ago I thought of a possible solution to this:

An idea struck me today. The Dynamic Playlists could be organized in a
similar fashion as the smart playlists.
*So, you would add a dynamic playlist to the collection, be shown a
dialog similar to partydialogbase currently plus a widget with all the
playlists possible for the Playlist Shuffle (with a checkbox for
each).
*You could drag or double click it like any other dynamic playlist
(perhaps dragging should incur one of those dialogs warning of its
destructive nature)
*There would need to be some method to indicate which dynamic playlist
is currently being played. Perhaps a bar across the top of the
playlist with the name of the currently playing dynamic playlist? This
would be nice anyways to indicate more clearly that you are in dynamic
mode.
*The dynamic playlists should be editable (they are not currently).
*There would be a selection of default dynamic playlists, so perhaps
partydialogbase wouldn't need the combo box anymore. It could assume a
Playlist Shuffle. Append Suggestions and Random could be default
dynamic playlists.

So the PlaylistBrowser KListView should sometimes have checkboxes and sometimes not. Sounds like a good time for inheritance, right? Actually no, and if it wasn't for `moc` I might of gotten away with it.

The problem is that to add a checkbox you have to use QCheckListItem which inherits QListViewItem. However we're currently using KListViewItem (to get the nice alternating background) which also inherits QListViewItem. So through normal inheritance its impossible to have an object that can have one or the other parent depending on the circumstance.

...unless you use a template, right? Since we actually subclass KListViewItem into classes like SmartPlaylist, PlaylistEntry a template could be used to determine at compile-time which parent class (QCheckListItem or KListViewItem) should be used.

However PlaylistEntry is a QObject (it uses threading to load playlists). `moc` forbides QObjects to be template classes. So I cursed moc and made a parent PlaylistEntry and had QObject and non-QObject subclasses. Once I figured out that I might have to do something similar with the KListView itself, I went to bed.

Today I implemented a much better solution, one that had actually been on the back of my mind the whole time. I iterate through the existing KListView and create new QCheckListItem's using the text() and pixmap()s of the KListViewItems. No refactoring needed.

Now I love the moc.