Yeah I’m old school like that! 🙂
Anyway, it’s been a while since I last blogged about Bangarang development so I figured I should share a little (or long) insight into what to expect for the 2.0 release with a few screenshots to help explain.
Before anything else, I need to mention that Stefan has been totally kick-ass with just about everything he’s tackled. He is the only other longer term coding contributor to the project and there’s absolutely no way I could list all the stuff he’s worked on, but I’ll mention a few: Lot’s of work on DVD support including subtitles, angles and audio channel support; Excellent star rating renderer that’s used all through out Bangarang; Shortcuts support and configuration; Filter support on the media list and playlist views; Tons of bug fixing, improvements and cleanup.
A good deal of my time and efforts over the last few months have gone into the InfoView. The InfoView is a sidebar showing information on the currently selected item(s). The information in the InfoView varies depending on the selected media items. I’ve already blogged about the Recently Played, Highest Rated and Frequently Played info boxes displayed in this view.
Most of the work on the InfoView since then has been focused on allowing easy, seamless interaction with displayed media information. Let’s start with artwork:
Representative artwork for categories such as artist and genre are created based on the artwork of media items in the category. Custom artwork can be set for artist and genre categories if for some reason the user would prefer to see say a picture of the artist or custom genre artwork.
The primary function of the InfoView is to display media info. A secondary function of the InfoView is to allow editing media info. This means that I did not want to distract from the primary function by using editing widgets to display information (which emphasizes interaction over information). I also didn’t want to switch from a “display mode” to an “editing mode” like in Bangarang 1.0 which exposed all the editing widgets for all fields at the same time which can be jarring. I also wanted to add support for browsing directly from the InfoView by, for example, clicking on the artist name to see all songs by that artist, or by clicking on the genre. On top of all that I wanted to add support for multiple artists, composers, genres, actors, directors and (nepomuk) tags. That’s a lot of functionality to stuff into a relatively small area, so it has taken some time to identify and implement a solution that is not overwhelming. Some of this was all front end UI stuff, some of this required work on the deeper plumbing. We’re finally approaching something I’m satisfied with:
The first image shows what the info view looks like normally – basically like a sheet of paper (very low interaction impulse). When the user moves the mouse over the values for each field, more functionality is revealed as shown in the second image (basically increasing the interaction impulse). The user can directly edit the field by clicking on it, add a value to the field by clicking on the “+” (2nd & 3rd image above) or browse using the field value by clicking on the browse “>”icon. So in the example provided in the 2nd image, if the user wants to see other Rock songs it’s just a click away.
For music files that support ID3 and Vorbis comment tags, multiple artists, composers and genres will be updated along with the nepomuk datastore.
Since users can edit info in the InfoView, I wanted create a framework that would allow metadata editing to be a little easier. Info Fetchers do pretty much what the name says… fetch info. Info Fetchers specify their required fields for each media type/category they handle and, when present, they’re exposed in the ui for user to add metadata with:
In the first image, after the user enters the url for an audio or video feed, the info icon is shown which, when clicked, offers a way for the user to fetch additional info. Fetched info (second image) is treated the same as information entered by the user. If multiple matches are found the are presented for the user to choose as in the third image. So far Info Fetchers have been created for fetching feed info and dbpedia info on persons(artists, actors, directors) and movies. More will be added over time. More recently, I learned from Sebastian about the nepomuk web extractor plugin framework that Artem Serebriyskiy has worked on. It should be possible to eventually write a Info Fetcher to use nepomuk web extractors to fetch media info. Once again, the work Sebastian and friends and doing on nepomuk is great and this is my personal appeal to the community to step up with whatever support you can provide (coding, documentation, whatever..). My intent is to prioritize Info Fetcher/web extractor plugin development for services that provide media related information in a philosophically libre sense. (Frankly, these are the services worth my time and effort rather than ones that lock up publicly available information behind a proprietary/pay wall.)
Note though that Info Fetcher need not exclusively work with the web. An Info Fetcher has been written to look at file names to extract season and episode numbers for TV shows. In fact this was a long outstanding merge request by a contributor which was easily converted to an Info Fetcher.
All the work has not just been on the Info View though. Files and folders have been overhauled to allow direct file system browsing from the traditional KDE Places:
File listings are progressively loaded with basic then full metadata so browsing is much, much faster than before. If you’re quite happy with the way you’ve orgainized files in your file hierarchy, Bangrang will allow you to browse that hierarchy with the same ease as every thing else. Additionally, as shown in the picture, whenever the user wants to they can index selected files or folders when they see fit, rather than being forced to (as in 1.0).
MPRIS support was kindly added by Ni Hui:
More recently additional ways to manage the Recently Played, Highest Rated, Frequently Played media lists were added:
There are several other changes here and there with just a few minor features left to implement for 2.0.
When’s 2.0 going to be released?
So Bangarang 1.0 was released in January of 2010. When I started on 2.0 I imagined I’d be able to get it out in 6 to 8 months. However, the reality is that in order for me to work on Bangarang I need to maintain a balance with all the other aspects of my life in order to enjoy working on this, my hobby. I’ve managed to find this balance in the last few months and that usually means hacking on Bangarang only on weekends. And that’s fine with me, cuz I’m really enjoying this and I really want to release something to be proud of. That said, I would like to release 2.0 soon. Which is part of the reason I’m writing this post. I’m happy to say that I hope to release the first beta in the next 2 to 3 weeks. If that still sounds far away, remember that’s 2 to 3 weekends – 2 to 3 hacking sessions for me. With all the new changes, unfortunately stability has gone down a bit so I’d like to spend some time doing a few rounds of bugfixing before the beta release. As always, I welcome any help that anyone has the positive motivation provide. There is a LOT of stuff I’m learning about as I do this, so there could be very simple things causing a crash that I’m simply uneducated about how to fix. So don’t assume there’s nothing you can do to help. 🙂
Thanks to all the translators who have provided contributions so far. You’re AWESOME! String freeze should be around the first RC (I’ll be sure to provide lots of heads up).
Well that’s it. Sorry for taking so long to provide an update. For those who are still interested after all this time, the source repository is here and there is a project mailing list is available here. Of course, you’re welcome to comment here.