My name in lights
I’m in this week’s Perl 6 Summary — in the perl6-language section, under ‘Hyper mutating methods’.
This pointless blog entry was brought to you by my ego.
I’m in this week’s Perl 6 Summary — in the perl6-language section, under ‘Hyper mutating methods’.
This pointless blog entry was brought to you by my ego.
This weekend seems to have mostly consisted of games of Worms 3D, periods of excessive Towel hacking (for which I must be grateful to Jonathan, who’s appearance on MSN the other day helped me get going on it even after a week of C++ programming at work), and periods of inexplicable lethargy and tiredness.
As it turns out, the best way to get over the latter is to spend a while going for the gold cup in Super Sheep Challenge 2, then to spend a while drinking wine and hacking Towel. Fixed a bug in the random track selection code today, did lots of work yesterday, and overall it’s becoming increasingly more useful. In fact, there’s not much more stuff on the list to go in before 0.2.0 can be released!
Woohooo!
Is ‘complicatedly’ even a word? No matter, it is now.
Anyway, I’m going along writing Towel’s new playlist code, and I realise some of the loops I’m going to have to jump through to keep the data within the playlist structure (which is like a tree kind of thing) synchronised suitably. I’m storing some information at each node rather than recalculating it each time it needs to be accessed, because it will work out alot more efficient that way. I don’t like to think of what kind of mess it would make if I had to recalculate some of this stuff every time the song changed. This data is needed to make random track selection reasonably fair, because the nested-group concept means I need to weight the random algorithm at each level so it would be more likely to go down a branch with 16 tracks in it than stop at the current level which contains only 3 tracks. Of course, it might do that anyway, but that’s what a fair random picker is all about.
I’m a little worried that the random algorithm might work out being a bit slow, actually, but short of implementing my own TreeModel, which I’m not about to do, I can’t really do much about it and keep the playlist working the way I want to.
Anyway, for now it’s moving along. Need to add some more data items for things like the current track, so it can keep tabs on it, and the code for next-track selection of course. Then we can finally plug it into Towel’s main code and make it play music. Jonathan’s nice GStreamer backend will be doing that of course, it already works with the old playlist. In fact, the playlist code doesn’t touch it at all, save for a little bit of use of his Towel::File and Towel::Loader classes to do filetype detection when a track is added to the playlist.
Also need to work out an efficient way of loading the playlist. Ideally I need to build the tree then calculate the metadata just once, rather than with each add, so loading from playlist files will need a special code pathway… thankfully a generalisation of the current one should accomplish that.
All fun though
What to say what to say? Well, let’s see…
My parents are coming next weekend, and we’re going out to dinner with my uncle who I don’t see very often, which will be nice because he’s probably my coolest uncle (not the weirdest though, that credit goes to one I see quite a lot). I hope the food’s good. I need to tidy my room.
Had a very unproductive day today. I started hacking on a little applet I want to write that’s basically a different version of the GNOME tasklist. I thought it would be fairly simple, other than that I wanted to write it using the C APIs instead of C++, but I thought it would be seriously evil when I realised that gnome-tasklist-applet has most of its work - including generating the appropriate widgets for tasks - done by libwnck! I didn’t really want to start playing with that, but happily I remembered the little icon on the right of the menu panel which has a task menu attached to it. Turns out it’s called the foobar-widget and it uses a different part of libwnck’s API to receive signals when windows are created, closed, etc. etc.
So I hooked into some of those and now get buttons appearing and disappearing, it’s cool. Now I need to figure out how to
a) turn it into an applet
b) make it use buttons like the panel launchers - I’m hoping these are accessible through the GNOME APIs, because if they’re not I’m into custom widget territory and that’s not something I want to do in C at this point in time.
Apparently it’s easy to make it instantiate Cost to ‘error’ when there’s an error, but at the moment mine’s just backtracking infinitely… and I can’t put a cut in it because if I do that it won’t backtrack to the error case!
I get the impression I’m missing something here. Oh well. In other news, I’m getting better at this ebuild-writing lark, and am now testing out one I just wrote for gtkmm-2.2.0_rc2. And all so I can test the candidate and make murrayc happy. Bah.
Powered by WordPress