Amarok

Yes, I'm still working on my GSoC project about statistics synchronization in Amarok. I've skipped one report, because last week I was busy with my university exam and real life. This week is another story, I've added synchronization preparation page ... [More] (so that you can check what to sync), implemented automatic non-interactive synchronization and more.New dialog this week: preparation for synchronization.What I've done this week:Factored Meta::Track::recentPlayCount() into capability, it didn't have much sense.Added above page for the first step of the synchronization, added Back button to the second page.Made Amarok remember syncing preferences: what fields and collections to synchronize. Local Collection and iPod collections are checked by default.Implemented automatic unattended synchronization: checked (or enabled by default not-unchecked) collections will be synchronized automagically as soon as they appear or on start-up (with some delay to let them settle). If ratings conflicts are detected, it will fall-back to interactive mode and you can make the background job interactive as well.Improved minor visual things (ratings are now nicely painted using stars) plus did some code clean-up so that first part of my GSoC approaches merge-ready state.Problems I've faced:I've fought with QTableView and sizeHint()s a bit, but I've won. :-)The dialogs probably need usability and design review, sure I'll contact KDE Usability group before merging.What's next:According to my schedule, I've fulfilled week 5 and week 7 with this (funny). More importantly, first part of my project is roughly done by this week's advancements, and I'm quite happy with the results. I think that the unattended synchronization is particularly useful: you just tell Amarok what to synchronize once and it does everything else for you; that's what 99% users will be using most of the time in my opinion.This week I'll finally start looking at Last.fm things. You can test my work by pulling and building gsoc branch of my Amarok git repository clone, it already works quite well! I also publish weekly diffs with more technical details on KDE's review board which may be a more convenient way to review my code and to comment on it: week 1 week 2 week 3 week 4 week 6 [Less]

Hi, in case you forgot, I'm working on my GSoC project about statistics synchronization in Amarok. This week, I've made the behaviour (as opposed to the looks) of the synchronization dialog perfect. Do you think I'm being too bold? Check the rest of ... [More] the post. :-)I add a couple of buttons each week, I promise I won't continue endlessly. :-)What I've done this week:Eliminated some false-positives in detection of rating conflicts (uses some heuristics, but will do)Made "Updated Tracks" and "Tracks With Conflicts" combo-box options enabled only if there are actually some such tracks.Made synchronization aware of iPod's recent play count feature - now the synchronized value is correct even if you play the same song in Amarok and on iPod simultaneously.Added status bar so that you know the counts.Qt's tree view combined with filtering can unfortunately forget which nodes are expanded. I've worked it around with some witty code. :-) On first show, tracks with conflicts have their nodes expanded.Added the "Take Ratings From" button.Problems I've faced:While I'm generally satisfied with the dialog's behaviour, its appearance isn't particularly pleasing. I will for sure fix minor things like displaying rating with stars, but I'm not a usability expert. Fortunately, there seems to be an easy way to get it reviewed now.To support iPods' recent play count, I've added a method to Meta::Track, which now seems rather unfortunate. I need to consult it with other Amarok developers, but probably I'll factor it into a Capability.What's next:Next week I'll make the synchronization dialog two-step: in step 1 you choose what fields to synchronize and what collections should participate.  What you see above will become the step 2.I'm still a little ahead of my schedule and that's good. This means that I'll have a chance to look into Last.fm realms sooner. There is some activity on Last.fm code in Amarok from Harald Sitter recently (great!) and it turns out that rather big re-factoring will be needed.You can test my work by pulling and building gsoc branch of my Amarok git repository clone, it already works! I also publish weekly diffs with more technical details on KDE's review board which may be a more convenient way to review my code and to comment on it: week 1 week 2 week 3 week 4 [Less]

Last weekend, after countless emails and weeks of digging through a huge Google spreadsheet, I have finalized Season of KDE selections. The KDE student programs team is confident that we have made the best possible choices and matched as many ... [More] students as possible with competent mentors. KDE student programs by the numbers Congratulations and a big welcome to all the students who have been accepted for Season of KDE 2012! This year we had almost 70 applicants. We found a mentor for 29 of them, and they will spend their summer hacking on KDE. Unfortunately, mentor availability was tight, so we had to say no to quite a few excellent submissions. I’m not complaining though, this year KDE got more Google Summer of Code students than ever before, and more Season of KDE students than ever before (total headcount: 89). It’s going to be an awesome summer! Help wanted: web application developers and artists It is clear that KDE student programs as a whole are growing, and we have reached the point where a single Google spreadsheet as a tool for all administrative tasks concerning Season of KDE simply does not scale. The sheer amount of submissions (and therefore, data), combined with the size of the KDE community (and therefore, mentors to contact) has resulted in the Season of KDE 2012 selection period taking more than a month! The current “spreadsheet+bunch of emails” workflow is definitely unsustainable, and the KDE student programs team agrees that a web application like Melange would help tremendously in managing Season of KDE more efficiently. Melange would probably be overkill though, and we have not managed to find any existing solution that would fit our requirements. Those requirements are quite simple: a web application with simple CRUD database operations that would allow the following: 3 categories of users, students, mentors and administrators can sign up, ideally through identity.kde.org; students can submit one or more applications for a currently active student program (e.g. Season of KDE); mentors can view submissions and declare their will to mentor one or more students; administrators can assign student-mentor matches, manage deadlines and properties of a student (active/inactive, shirt sent/not sent, etc.); mentors can pass or fail students with a simple yes/no switch (no need for questionnaires like in Melange). Lydia Pintscher has drawn up a nice representation of the workflow we would like to have: Sayak Banerjee has already started working on it, so we are hoping it could be ready for next year’s Season of KDE. If you wish to help, feel free to contact sayakb on #kde-www on Freenode. We could also use a nice logo for Season of KDE, if you have drawing skills and would like to help contact the KDE student programs team at [email protected]. [Less]

Hi, in case you forgot, I'm working on my GSoC project about statictics synchronization in Amarok. Previous report was rather early, this one is a bit late. The main success this week is that the synchronization actually works (best tested with ... [More] iPods), hooray!Progress on the Synchronize Statistics dialogue. You can see conflict resolution, updated fields would be in bold, but the are none.What I've done this week:Implemented ability to compute synchronized value for each field, this is shown in UI. Fields that are going to be updated are in bold.Improve the UI to be able to sort, filter-as-you type and filter based on synchronization status (updated, not touched, having conflict).Made the synchronization smart so that it for example doesn't want to update labels of an iPod track, which doesn't support labels at all.Changed core Amarok classes so that first, last played time and play count can be written back to tracks.Implemented actual synchronization worker on top of all this. The worker runs in a thread and is abort-able.Problems I've faced:There is currently no way to determine what statistics fields are supported by given Amarok collection. I had to use some heuristics as a temporary solution.Setting some track fields is inconsistent in core Amarok classes. For example setRating() and setScore() are in Meta::Track while I really think they should be in a specialized class called EditCapability.No other collection than the main one supports track labels currently (AFAIK), so I cannot really test this feature.What's next:I've already done much of the agenda for the next week, so:I'll work on polishing the synchronization UI and behaviour a bit more to remove some corner-cases that currently exist.I'll improve handling of rating conflicts: I plan the "Take ratings from..." button to mass-resolve unresolved rating conflicts.You can test my work by pulling and building gsoc branch of my Amarok git repository clone, it already works! I also publish weekly diffs with more technical details on KDE's review board which may be a more convenient way to review my code and to comment on it: week 1 week 2 week 3 [Less]

People have been talking recently about zombie attacks, pointing to them as signs and portents of our impending doom as a race. At first there was the story of the man who ate the face off a homeless man. He was shot by police, refused to stop eating ... [More] the man's flesh, then shot some more until he died. Next there was the story of the guy who had someone's bones in his basement and was found later to have eaten him.  I'd like to point out that while the first story is a genuine sign of the zombie apocalypse to come, the second is just some weirdo doing a particularly bad job at being a cannibal, which is to say perp #2 should have been wearing the bones, not leaving them alone in the basement for relatives to see. Having dismissed the second incident to general human weirdness, and barring further evidence of an impeding lycan revival, I started thinking about ways in which the 1st zombie attack might signal the start of the zombocalypse. You see transmission, is what we would have to worry about next. I've been pondering ways in which this might happen. Initial reports from the authorities are saying that this attack was due to drugs and honestly, I can believe it. A drug that modifies brain behavior and affects the endocrine system (releasing small bursts of adrenaline leading to temporary superhuman strength) is feasible.  Furthermore, if the effects were somehow sustained and muscle activity was constantly being stimulated - instead of the typical stimulation/desensitization cycle nerves (and their connected muscles) experience - the constant activity of the nervous system could indeed lead to increased internal body temperature. After all, we "burn energy" when we need it, and one of the most common results of energy being converted from form A to form B, is the loss of some of that energy in the form of heat. But for the zombocalypse to occur this behavior must me transmissible, and sustainable. What we need, is a virus. Now we know from crackbabies that certain dependencies of a drug can be passed on from mother to child. I propose a scenario where someone who is with child takes this drug. The drug manages to get into the baby's system and thereby messes with the nervous system of the still forming child. But wait, there's more! In addition to this drug, the mother has a virus, let's just grab HPV from the existing mother to child transmissible virus pile and run with it.  Once birthed the child infects an adult, and the virus is able to accelerate its growth due to the proper nutrition of its new host. Crackbabies, since the mothers are mainly doing drugs, rarely have proper nutrition. Such would be the case with our zombie baby (Zombaby). But once the virus is transferred to a healthy individual, replication would be through the roof, thereby decreasing the time to zombification. The story of how this happened for the technical minded might go a little something like this: Our mother has already taken the drug and started chewing on her boyfriend, so she has to be put down by the police. It is of course captured on video but all the public see is a potentially deranged, pregnant woman, getting gunned down by the police. It doesn't matter that from the police's angle they couldn't see the womb, so now there needs to be some spin to put a positive angle on this. They try to save the baby.  Meanwhile inside the amniotic sac, the virus in combination with the drug, has given birth (see what I did there) to a situation where the HPV is now able to make its way to the brain. The drug has somehow managed to turn on the transcription of genes necessary for the fight or flight response. The new brain HPV recombines with these genes and incorporates it into its own genome. The virus then starts making more of itself. We have just witnessed the birth of HZV: the human zombie virus. Thankfully, this strain can only induce the "zombie response" from direct human to human contact.  Speaking of which, the doctors have begun there emergency C-section to save the baby. The doctors successfully deliver the baby and it cries. They notice that this freak of a child is one of those that already has all its teeth in (yes, this happens IRL). Regardless, they take the baby to the the nursery. Later, a nurse comes in to clean, and feed the baby before the inevitable press conference that the hospital has called to announce that they were able to successfully deliver the baby.  The nurse, tries to feed the baby formula but it keeps crying and spitting it out. Finally it throws up while she's holding it, projectile style. Right into her eye. Not expecting this surprise the nurse drops the baby accidentally. The virus, having saturated the baby's bodily fluids, travels along with the projectile vomit. We now have patient zero. And after being introduced into a well nourished adult with ample energy reserves the virus makes its way to the brain via the eye. Colonizing nervous cells as it moves along. This results in what will become the notable bloodshot appearance in the eyes of the zombified, indicating that they have well and truly "turned".  And so it begins? I guess we'll see :-)  I did write more but this entry was getting too long, and possibly too technical. If I do decide the finish this tale of intrigue and romance I'll probably do it over at http://thebennettproject.com once it launches. That's the new site I've been working on, in addition to doing some freelance web dev projects. [Less]

We Need You! As already announced by Harald on Kubuntu.org, we need new members for the Kubuntu Council. Don’t forget the deadline next weekend! Hurry up, get your wiki profile updated and submit your candidacy to the Kubuntu-devel mailing list. I decided to run, what about YOU?

We just published Amarok 2.6 beta 1 and need testers: You can get the tarball from the link on our homepage or ask your friendly distribution packagers to package it for you. Some might already have done that anyway To build from the tarball, you ... [More] can follow the instructions from our wiki. Please focus mainly on the new features listed in the article and in the ChangeLog as well as the features you use most, but please also have a look at the (still incomplete) list of tests. Feel free of course to add tests to that list, too. We would be very glad if you could report the bugs you find right away by using this link: Enter Bug: amarok. Feel free to ping me (Mamarok) in #amarok on irc.freenode.net if you need more information. Happy testing! [Less]

Hi, in case you forgot, I'm working on my GSoC project about statictics synchronization in Amarok. This is my second weekly report which comes a bit earlier because I'll be travelling to Budapest till the end of the week, but check the diffs, I've ... [More] already done a week's worth of work. (or more :-)UI showing how tracks from 3 collections are matched. Unique & Excluded tracks work, too.What I've done this week: Visible feedback for the job that matches tracks (little progress bar).Renaming of core classes to have shorter names; all are in a namespace so no clash threats.A class to handle one synchronization from start to finish (names Process).2 models (QAbstractItemModel subclasses) for matched and for single tracks to power the UI + helper model to share code between them.Rudimentary UI for showing matched and single tracks as shown on the screenshot.A bunch of smaller fixes to keep the code clean and maintainable.Problems I've faced: QStyledItemDelegate cannot display rich text. :'-( :'-( QHeaderView cannot have minimum widths per each column. :-( Keyboard navigation doesn't work in QTreeView once you set selectionMode to NoSelection.What's next: Performing the actual synchronization. Shouldn't be hard as everything is prepared by now.You can test my work by pulling and building gsoc branch of my Amarok git repository clone, it already works (somehow)! I also publish weekly diffs with more technical details on KDE's review board which may be a more convenient way to review my code and to comment on it: week 1 week 2 [Less]

Hi, in case you forgot, I'm working on on my GSoC project about statictics synchronization in Amarok. This is my second weekly report which comes a bit earlier because I'll be travelling to Budapest till the end of the week, but check the diffs, I've ... [More] already done a week's worth of work. (or more :-)UI showing how tracks from 3 collections are matched. Unique & Excluded tracks work, too.What I've done this week: Visible feedback for the job that matches tracks (little progress bar).Renaming of core classes to have shorter names; all are in a namespace so no clash threats.A class to handle one synchronization from start to finish (names Process).2 models (QAbstractItemModel subclasses) for matched and for single tracks to power the UI + helper model to share code between them.Rudimentary UI for showing matched and single tracks as shown on the screenshot.A bunch of smaller fixes to keep the code clean and maintainable.Problems I've faced: QStyledItemDelegate cannot display rich text. :'-( :'-( QHeaderView cannot have minimum widths per each column. :-( Keyboard navigation doesn't work in QTreeView once you set selectionMode to NoSelection.What's next: Performing the actual synchronization. Shouldn't be hard as everything is prepared by now.You can test my work by pulling and building gsoc branch of my Amarok git repository clone, it already works (somehow)! I also publish weekly diffs with more technical details on KDE's review board which may be a more convenient way to review my code and to comment on it: week 1 week 2 [Less]

Hi, I'm Matěj Laitl and this summer I've been accepted to GSoC for Amarok to work on statistics synchronization between various collections and scrobbling services such as Last.fm. Here comes my first weekly report, enjoy reading it. :-) In short ... [More] , I've worked on a background worker that will associate same tracks from various sources with each other.Obligatory screenshot. Current visible effects of activating that action are none. :-)What I've done this week:Designed core (abstract) classes that will facilitate statistics synchronization for both collection and online service tracks: TrackDelegate and TrackDelegateProvider.Implemented these interfaces for tracks from Amarok collections (e.g. Local Collection, iPod and USB Mass storage ones...).Implemented controller, singleton class that is entry point to synchronization functionality in Amarok.Implemented MatchTracksJob, a job that runs in background and matches tracks from multiple providers into track tuples with same meta-data.Problems I've faced:Encapsulating asynchronous API of some Amarok classes (QueryMaker) to be synchronous and thread-aware was a bit tricky.I had hard time implementing lessThan() comparison function that needs third argument for Qt's qSort(). Function template did the job, but that made MatchTracksJob non-reentrant. :-(It isn't clear what meta-data should participate in track matching. Some sources provide few of them (Last.fm provides just artist, album, title; sometimes less) while Local Collection and friends can provide much more. I've made MatchTrackJob generic with regards to matched fields with artist, album, title being mandatory and composer, year, track & disc number being optional.What's next:We've ongoing discussion with Bart Cerneels whether TrackDelegate is redundant or not. I've made sure to code in a way that it can be replaced in future without hassle.The GUI to show matched tracks, providers etc.You can test my work by pulling and building gsoc branch of my Amarok git repository clone, but beware that it currently contains an unrelated change (pending to be merged) that will make your Amarok database temporarily incompatible with current Amarok git master. Update: the change has been merged! I also publish weekly diffs with more technical details on KDE's review board which may be a more convenient way to review my code and to comment on it: week 1 [Less]