Amarok Blog

Thursday, October 27. 2005

How I Learned to Stop Worrying and Love the `moc`

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.

screenshot

Posted by eean in eean at 19:21 | Comment (1) | Trackbacks (0)

How I Learned to Stop Worrying and Love the `moc`

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.

Posted by Ian Monroe in eean at 19:21

Serious Fundraising

We're about 4 days away from the end of the fundraising drive, and I am really quite taken aback by the generosity of some people. We have had single donations of 100EUR and higher, as well as poor college students skipping lunch for a couple of days to give $5.

Of course, this pales in comparison to the value of the time many dedicated people have put into the development of the product, but I know it is done out of their love for music and their love for amaroK. So for them it may not seem like a donation, since it is something they enjoy working on. So to enable the effort to continue because so many users sacrificed some money to allow project expenses to be paid requires a gigantic thank you.

If you have given, thank you; if you have not given and are able to, please do. If you would like to contribute but cannot afford the expense, we always welcome spreading the word, either by telling people about amaroK, giving away copies of the amaroK LiveCD or by simply using it and providing feedback to make it better. Those are all invaluable contributions in and of themselves, and are a big part of what makes FLOSS work.

As we come upon the end, it is becoming clear that we probably won't make the goal without either extending the deadline or having a large benefactor come through and makeup the difference. Not sure what to do yet, but I guess we wait to see what the weekend brings.

Thank you again for your support, and roK on!

Posted by Greg Meyer at 13:49 | Comments (0) | Trackbacks (0)

Tuesday, October 25. 2005

Getting organized

Development of 1.4 has started and some interesting ideas are going around. One of the things I'm working on is a feature to help you organize your collection files. Currently my collection consists of two directories /mnt/music and /home/mike/music_temp. In /mnt/music I have all the music I plan on keeping in my collection, and in /home/mike/music_temp I put music I just want to try out.

So now I've listened to these new tracks and want to put them in a nice tidy spot on /mnt/music. Now with a quick drag and drop from konqueror I can move them there. But this leaves us with a small problem. The tracks I liked so much now have clean stats

.

This is where Organize files steps in. I go to the Collection browser to find my new favorite tracks. Looking at all the artists it seems it could take a while to sort through and find all these tracks. Let's not forget where we have the files saved, /home/mike/music_temp, google like search to the rescue. In the search bar I type "Directory: /home/" I'm left with just the temporary files I want to organize.

I select what I want to organize and from the right click menu choose Manage > Organize Files... A dialog appears allowing me to choose the collection folder as the destination. I also have options like grouping all artists alphabetically such as "A/Artist/Album" and using the cached amazon artwork as the icons for each albums folder.

Click Ok and amaroK goes to work moving the files to /mnt/music/T/The Prodigy/Experience Expanded. Each track is moved here and renamed by it's tags, and the folder icon is set to the album cover. All this time, the stats are saved and the filesystem is orderly for when you use a file browser.

The feature still needs polish and has a few minor bugs but seems to be working good so far. Keep your eyes on the blog for more exciting features to come to your latest amaroK svn.

Posted by Mike Diehl at 20:37 | Comments (10) | Trackbacks (0)

Saturday, October 8. 2005

Context Menus & Options

burn_context I’d like to say that I am quite proud that amaroK has no context menu which has more than 9 entries. We like to keep options minimal, and our settings toolbar menu has only 11 entries.

But there is one thing which has been bothering me, and I don’t know the answer. I’ll be specific. amaroK has the ability to write cds if k3b is installed. There is always a burn menu in the context menus, which is menu entry is disabled if k3b was not found during compilation.

Is it better to remove entries which can never be used by the user, or to keep them disabled, and hence alert the user that such features are available?

I’m strongly leaning to the former, and remove anything that can’t be directly used. After all, the user would need to recompile/install the application to gain advantage and be able to use the this feature.

Posted by Seb Ruiz in sebr at 21:46 | Comment (1) | Trackbacks (0)

Sunday, October 2. 2005

Holidays, Fundraising, Live CDs & more

It’s been a hectic two weeks. University got the better of me, then I forgot about it and went down to Melbourne for 10 days. The best thing I have done in a while - to get out and forget about everything which was bombarding my world.

It’s now a public holiday in Sydney, 31°C and beautiful weather. I’m planning on going down to the beach soon.

In the world of amaroK, we have launched a fundraising campaign to aide us in reaching a couple of goals - developer meetings, web hosting (amarok.kde.org currently uses over 50Gb of traffic a month - thats not cheap. Thanks to http://pwsp.net), and maybe even some hardware. We are aiming to reach US$5000 before November, so if you would like to give a hand, we would be very appreciative.

Additionally, the amaroK 1.3 live CD has just about gone live. Excuse the pun . With 26 wicked tracks to listen to, the best of KDE and the ability to remaster and create your own CD with your own music, what’s not to love about the CD?