Entries by Ian Monroe

Gentoo and Xine dev (and part-time "Amarok Helper") Diego wrote an interesting blog about memory usage. Or, at least interesting to folks like me who somewhat regret never having had a operating systems class. He discovered that any Xine client (which includes Dragon Player or any KDE4 app that makes a sound) wastes 1.7mb of RAM thanks to libvorbisenc.



Using his cowstats script, I profiled Dragon Player:

File name                                                       | .data size | .bss size  | .data.rel.* size


src/app/CMakeFiles/dragon.dir/playDialog.o                          0            1            0


src/app/CMakeFiles/dragon.dir/videoWindow.o                         0           17            0


src/app/CMakeFiles/dragon.dir/mainWindow.o                          0           17            0


src/app/CMakeFiles/dragon.dir/actions.o                             0            1            0


src/app/CMakeFiles/dragon.dir/playlistFile.o                        0            1            0


src/app/CMakeFiles/dragon.dir/fullScreenToolBarHandler.o            0            1            0


src/app/CMakeFiles/dragon.dir/stateChange.o                         0            1            0


src/app/CMakeFiles/dragon.dir/theStream.o                           8            9            0


src/app/CMakeFiles/dragon.dir/fullScreenAction.o                    0            1            0


src/app/CMakeFiles/dragon.dir/main.o                                0            8            0

Not too shabby. Also not so important, Dragon Player isn't a library. I just profiled libamarok which is loaded by all the various Amarok plugins so potentially could be an issue. It had 46k copy-on-write sections total, but out of the dozens of files 40k is a variable in the crashhandler, which is a kind of scary piece of code since it has to work while the rest of Amarok is crashing. So I'll let someone else work on that.

Awesome release everyone!



Having KDE4 officially released is making my life easier. Thanks to everyone's favorite MOTU Harald Sitter, Dragon Player is now in gutsy-backports. I've just pointed this out on the Dragon Player website. And Long-time Rokymotioner Enr1x has created an AUR for Dragon Player. So all this makes Dragon Player easy to install, I can't wait for Amarok 2 to reach this point! Dragon Player 2.0 final will then be released in a couple of weeks probably

.

I do plan on working a bit more on subtitle/audio channel issues to make sure it works cleanly. I do feel that I'm spending probably a lot of time on this feature, but I suppose it isn't a surprise given that its one of the few features where I can't just hook up to a Phonon signal and rely on Kretz's code to do all the work for me. And once KDE 4.1 is out, I'll be able to tear most of even this code out.



So as my Dragon Player TODO list has mostly been reduced to testing a couple of things, its time to get back into Amarok 2 code. Hydrogen will be proud of me. I've identified podcasts as really the remaining "why I still have Amarok 1.4 open" issue. Bart has worked a lot with it already, I'll have to see what he has done so far.

As promised, Dragon Player 2.0 beta1 has been released.



Bug reports and feedback appreciated. Especially on the volume slider, I'm not sure I like having the extra toolbar button.



There's a few more items on the TODO list (mainly double checking stuff works) and then a 2.0 final release can be made.



I've also updated the Codeine kde-apps page to reflect the name change. Now to update the Freshmeat entry (not sure people actually still use Freshmeat though, but it can't hurt.)

So Dragon Player is moving into kdereview for at least a couple of weeks before perhaps moving on to KDE Multimedia.



To update your SVN checkout do:

svn switch svn://anonsvn.kde.org/home/kde/trunk/kdereview/dragonplayer



There should be a beta release soonish. I consider Dragon Player mostly ready for a 2.0 release, just a bit more polish and some more testing (which is where the beta would come in).

So I'm visiting my parents in Fulton for the holidays. My laptop doesn't really have the horsepower to compile kdelibs or Amarok, so I've been continuing work on Dragon Player (when not eating chocolate oranges or cookies anyways). Mostly just odds and ends. I have a KPart version of Dragon Player that links and installs, but I haven't actually figured out how to test it (it shows up in Konqueror's configuration, but Konqueror never appears to use it).



I've setup a website for Dragon Player at Kollide, the server brought to you by PBS Amarok Users Like You. The scary screenshot is thanks to the trailer from some movie called Dragon Wars I hadn't heard of before, but it seems appropriate. I actually had to hack phonon-xine to display using the "xshm" video output, otherwise it wouldn't make a screenshot.



You can see its a rather barren website for the moment. I actually like the current Dragon Player icon (the Codeine movie clapperboard icon), but I really could use a Dragon and movie-themed logo for the website and to fill up the black space when no movie is being played. Any volunteers?

First off, I've graduated Truman State University with a Computer Science major. Hooray! It's been a good 4.5 years, I would do it again.



So I've decided to rename Codeine/Video Player to Dragon Player. Its named in honor of KDE's mascot Konqui of course. I've always been a fan, I requested and received a Konqui shirt back when I was in 11th grade for my birthday (which is 3 or 4 years before I started coding for KDE).



I've also gone ahead and made a release, Dragon Player 2.0 Alpha 1. I hope to generate some feedback and interest from KDE4 distributions (I believe Mandriva is already packaging it from SVN). There's still some rough edges and it doesn't have some features I plan on adding in the final form, but its pretty much there. The most notable part missing is the KPart, I do plan on working on that pretty soon.



Dragon Player doesn't have a web page yet, that should come out soon.

Just read that Terry Pratchett has a rare early onset Alzheimer's. As he points out he ain't dead yet, but its still sad to think about the decade or two or three of books that now won't be written (assuming he doesn't pull a Stephen Hawkins).



In Pratchettian style he notes that frequently people want to help in such situations, but he'd only accept offers from "very high-end experts in brain chemistry."



In entirely unrelated news (and just to make this somewhat KDE related), Video Player should start remembering your position when you reopen a video pretty soon. While poking around the Phonon API today I remembered the issue I had with adding a context menu to fullscreen mode when I was working on it back in the Spring... but thats for later.

Recently I've been working again on Video Player; see the blog announcing Video Player if you wondering what I mean (the summary: its Codeine 2.0). It's codebase is nice and small so its pretty easy to make some progress. First thing I did was remove the remaining dependencies on KDE 3 Support and Qt 3 Support. I can't really say its fully ported yet, but its certainly no longer using any deprecated APIs. Thanks to some help from Matt Rogers of Kopete fame, it also no longer crashes on exit. In fact it has no known crashes, an important milestone with any software, though a state that's usually short-lived.



Phonon in KDE 4.0 will not have APIs for subtitle or multiple audio streams (like on DVDs and .mkv files). So Matthias Kretz added a property to the Phonon Xine backend to give direct access to xine_stream_t, an important data structure in Xine. I was able to use this property to add subtitle support for Video Player. Currently it doesn't have any way of knowing when a new subtitle is available (for instance on a DVD, the title screen may have no subtitles, but then they are available when you start playing the movie), and it just asks Xine every 5 seconds. Hopefully I can find some solution for this, perhaps from the Phonon Xine engine or directly from Xine.



This all means Video Player will have a direct dependency on Xine and the Phonon Xine engine until at least KDE 4.1 (though it could probably work with other engines, just without subtitle or multiple audio streams).



When I have more time (I have a Stat final tomorrow) I plan on fixing up all the little features that make Codeine great, mostly involving keeping state.



I actually do have an idea for a less generic but still simple name for Video Player, but I'll keep it private until I buy the domain.

An important anniversary went unnoticed last month - Amarok turned 5. According to main.cpp Amarok was created on "Mit Okt 23 14:35:18 CEST 2002". At least we were celebrating Roktober anyways.



Importing Amarok into Git has several advantages. `git grep` is the recent favorite. I've always been a big fan of `git log`. So in celebration of Amarok's birthday, I just finished writing up a little Ruby script that uses git log output to create a CSV file which I made a graph out of below. Apparently Amarok wasn't under version control, or at least not KDE's, until about Sept. 2003. Code here.



The top graph shows the number of line adds + number of line deletes; the bottom shows the total number of commits. You can see when the Amarok 2 branch was opened pretty clearly on both. It doesn't show what's been going on in any of the branches, notably the stable 1.4 branch that opened up at the same time Amarok 2 did.

I don't keep it a secret that my grudge against Apple is somewhat personal; about a month after DAAP support was added into Amarok, iTunes 7 was released which dose not allow third-party applications to browse its DAAP server. That after I had worked hard to make Amarok function with the already discovered iTunes v4.5 DAAP hash. (iTunes 7's DAAP hash still hasn't been recreated, it probably doesn't help that the people who setup a site for to figure out the hash make a product obviously meant for piracy ARRGH! on campus networks.)



So its nice to see some growing awareness that Apple doesn't play nice, even in the somewhat mainstream media like BBC news. That gives a good overview of the case of "if Microsoft is a monolopy, then so is Apple." I really don't care whether the EU takes action against Apple. Hindering your customers in using your product is generally bad. You don't have to be a monolopy to do that.



On a somewhat related note, my last blog was 'breaking news' so it was neat to see it get picked up by Digg twice, Slashdot, Heise, Ars, and Boingboing.

As recently reported on Slashdot, Apple, in its infinite wisdom, has added a checksum to the iPod database apparently to restrict non-iTunes products (like Amarok via libgpod) from having the ability to add music. To me this sounds pretty familiar. This is the same thing they did to iTunes 4.5 to make it harder for other apps to read off their DAAP shares, they changed it again in iTunes 7; open source apps are still unable to read iTunes 7 DAAP shares.



But there's better news on this iPod front.

From #gtkpod today:

<wtbw> okay guys

<wtbw> i think we're done.

<wtbw> let me code something just to check

[30 minutes later]

<wtbw> can i hear a fuck yeah?

<wtbw> works for both mine and xamphears :>



wtbw suggested donations from thankful users go to Cancer Research UK.



Really the only "correct" solution is for folks to stop using Apple products. The iPod might have its own version of DAAP's iTunes 7 which has a checksum more difficult (apparently) to crack. But for the time being, things are fine.

Upgraded to the latest Git last night. From the responses to the previous blog and #git chatter I knew I had git stash to look forward to.



And this morning it has already come in handy. Last night I started a small refactor of the TrackAdvancer class (it now has a previousTrack method and needs to be renamed) but then went to bed and left Amarok uncompilable in my local copy. So to compile the latest Amarok this morning (the top toolbar has a nifty new SVG background) all I had to do was git stash, git svn rebase and then build. A git stash apply puts the local changes back in and I continued working on it.

I've been using Git for a couple of weeks now. Really I have mixed feelings about it. There's a million commands, many of which are redundant. Its obvious no one sat down and thought about what commands would make sense. However it is really fast. Having a git log that takes half a second is just handy. And unlike SVK, it does have a wealth of documentation.



In the future we might do Amarok feature branches in Git... SVN branches are just so horrible.



It took about 6 hours or so to fetch Amarok from SVN, it was more then 600 megabytes before "repacking" (why is it repacking when I've never packed before? some implementation detail being shown in the command name undoubtedly). But unlike SVK its easy to share your Git with others. So I'll spare you the trouble. You can git clone it from http://kollide.net/~eean/amarok.git , but then none of the git svn functions work. So more useful is the tar ball.



Then do something like this:

tar -xvf amarok.git.tar

mkdir amarok

mv amarok.git amarok/.git

cd amarok

nano .git/config #change the SVN settings

git checkout .

git svn rebase #rebase... obviously that means pulling in new changes right?

git log

...edit...

git commit -a

git svn dcommit #push to SVN.



Issues:

• Its currently impossible to easily lump seperate git commits together.
• You can't git svn rebase if you have any uncommited files. So do something like this:
  
  git commit -a
  
  git svn rebase
  
  git reset HEAD^
  
  HEAD^ is somehow supposed to mean the previous commit. This presents you the new changes from SVN and your code is still uncommited, so that it doesn't get pushed to SVN as a separate commit.

Anyways I didn't mean to turn this blog into bashing git, but oh well. Git is a neat piece of technology so its just more frustrating that its UI isn't more thought out. This extends to its GUIs btw... don't bother with the Qt4 Git GUI, it looks exactly like the Tk one.

Nikolaj is busy uploading his aKademy photos.



I liked this one:

Foreground: Martin, Bart and Wendy

Background: Me and Leinir

In-between: Some guy

In yesterday's blog I talked about my issue of wanting to use (animated) GraphicsView's in an Interview system for Amarok's playlist. Ivan ?uki? pointed me to a 2006 Trolltech Developer Days presentation about Advanced Item View. The presenter did show a pretty brute force way of doing animations in delegates, by just firing a timer every 40 ms. I tried this out two different ways.

First was similar to how he did it, firing a timer. It was not to my great surprise that this resulted in 30% CPU time for just one row needing to be animated, and it went up from there as additional rows were added It actually still looked and reacted fine though, so before I noticed the CPU usage I was feeling like I had cracked the case.

Then I tried it by connecting (indirectly, since I had to translate a QGraphicsScene into a QModelIndex) QGraphicsScene::sceneRectChanged to QAbstractItemView::update. However this didn't work. Apparently QGraphicsScene doesn't consider a flashing cursor as a scene change worth mentioning?

So now I'm basically back to where I was. Except the presentation did hold out another possibility of subclassing QAbstractItemView and then doing setViewport. This is what he did for the QGLWidget views that he made (instead of just writing a view from scratch). However its not quite clear to me what the QAbstractItemView provides when you override the viewport. More importantly none of the examples had scrolling, so they just painted the whole area all the time. And figuring that out is the biggest issue with perhaps using a QGraphicsView (whether by itself or as a viewport of a QAbstractItemView.)

More Playlist Details

Benjamin Meyer had a few questions about the playlist that I'll address here:

• I think Ben you know what the playlist does. The user queues up music to listen to and can also edit their tags.
• I see no reason for multiple views.
• Animations - yes. I don't know if I'll have time to do cool animations this summer, but I do want to have a framework in place where someone could implement nifty animations easily.
• Editing - currently the reason I want to get animations to work. Users can do some basic bulk tag editing using the playlist.
  
• As far as what the playlist looks like, its the thing on the right in Nikolaj's most recent blog. In the future we want to do more complicated things such as grouping tracks from the same albums together.
  
• Each row is a single cell, so the entire row is drawn in a single delegate paint. So the view itself is a fairly basic subclass of QListView.