[Rhythmbox-devel] GSoC - DACP in Rhythmbox: Weekly Report 2
- From: Alexandre Rosenfeld <alexandre rosenfeld gmail com>
- To: rhythmbox-devel gnome org
- Subject: [Rhythmbox-devel] GSoC - DACP in Rhythmbox: Weekly Report 2
- Date: Sun, 6 Jun 2010 20:56:09 -0300
- What have I done this week?
As expected, I havent done much new coding, instead I've been fixing a few issues from hurrying up the code in the first weeks. I've just changed the pairing code to use DMAPConnection instead SoupServer directly. This makes pairing async and allows us to parse the response, but I haven't yet added the DACP structures, so the parsing fails right now. I thought I'd need to refactor DMAPConnection, but it seems the current code can handle my needs just fine. I just need to find a way not to leak the DMAPConnection, which I think it is right now.
I've spent quite some time hunting down why there was an assertion failing when the DACPSource in Rhythmbox went away. It turns out it was a problem caused by the CD Recording plugin in Rhythmbox, which was easy to fix once I knew where the problem was.
I've also received some feedback from my mentor from my code, which I've been trying to fix the problems. It was pretty cool when I learned more about GObject properties, GValues and a bunch of stuff, which was very useful to fix a problem with the API my mentor pointed out. It turned out I could've used G_TYPE_STRV instead of GValueArray which I used and it would be much more simpler, but well, I'm still learning GObject and it was worth it.
- What will I do next week?
I'll try to finish the ctrl-int path handling, at least some basic stuff. This should allow the Remote to finally believe Rhythmbox is a Remote library, because up until now it shows Rhythmbox on the list of servers after pairing but it's never able to connect to it. I'm also having some segmentation fault when handling the /databases path, which is the same code used in DAAP, so this shouldnt be happening and I'll need to investigate where is the problem.
- How accurate was my planning?
I was quite accurate, because I knew I wouldnt have much free time, even tough I spent much more time then I expected. I did however tried not to add new features to not complicate the code even further.
I learned that many times problems happen not because of your code, so I have to check a wider range of code when hunting for bugs.
I also learned a lot about GObject, most from Googling. Also found that DevHelp is really cool and can help a lot.
Also git can be very cool. I found out about mergetool and difftool, which used with meld turns out to be very helpful, powerful and simple. Sometimes git pays off for it's over-complication.
Until next week,
Alexandre
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]