Thursday, October 27. 2005How 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 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. 
Thursday, October 27. 2005How 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 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. Thursday, October 27. 2005Tuesday, October 25. 2005Getting 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. Saturday, October 8. 2005Context Menus & Options
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. Sunday, October 2. 2005Holidays, Fundraising, Live CDs & moreIt’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 |
Amarok LinksCalendar
QuicksearchCategoriesSyndicate This BlogBlog AdministrationWe Listen To... Powered by
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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.
. 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?
