Rain

It's rainy and windy today, and not at all sunny. I know I joke a lot, but I really do miss the rain. It actually is pretty boring to have sunny, warm days all the time. Not that I want to move back to Ithaca or anything, but it would be nice to have some rainy days distributed evenly throughout the year out here in CA, rather than getting 2-3 months of almost nonstop rain. Ah well. Nobody's perfect, even mother nature.

Eight is Special

Seriously?

Update: A quick grep through the gaim sources for the current CVS head shows that gaim_add_eight() isn't actually used anywhere in the code (anymore, at least). Ah well.

Xfmedia Refactoring

I've finally started my huge Xfmedia refactoring project. The idea is to make it a lot more maintainable and modularised. I've been doing this in tiny pieces for many months now (XfmediaPlaylist, XfmediaVideoWindow), but I can't really go any further without ripping huge pieces of the codebase apart and stitching them back together the way I want everything to be. I realise it's been a couple months since I released 0.9.1, but it'll likely be a couple more months (at best) before 0.10.0. I think 0.9.1 is fairly stable and featureful. Unfortunately, 0.10.0 probably won't have many user-visible changes, but I expect the plugin interface will finally be stable, or at least in a state where I can promise backward-compatibility for future releases.

Anyway, here's an initial sketch of how my current thinking looks with regard to object structure:

XfmediaApplication: This is more of a meta-object, but it'll keep track of "global" data and handle starting up the app, as well as tearing it down. I haven't decided yet, but it eventually may make sense to allow XfmediaApplication to instantiate multiple xfmedia main windows in the same process, so you can have multiple copies of xfmedia running in the same process space. I'm not really sure what this means for plugin interaction yet, so this may never become a reality. I doubt 0.10.0 will have this ability, but maybe in a future version.

I'm a bit less certain about how the next two objects fit.

XfmediaPlayer will be a very thin layer on top of XfmediaXine. It will know how to play streams and handle usual playback operations, as well as interact with the GUI.

XfmediaMainWindow is a GtkWindow representing the controls/playlist window. It'll act as a container for the XfmediaPlaylist, and hold the time label, song/status label, and control buttons and slider.

I'm not sure if XfmediaPlayer should be the container for XfmediaMainWindow, or the reverse. On one hand, it makes sense for the window to contain the player, but I think I'd rather have the player as the super-object, which will hold the main window, and know that it should do some UI-related things when playback events occur. E.g., if a stream is started from the stop state, the play button in the UI should change to a pause button. There doesn't seem to be a great way to handle this case with the reverse relationship.

So I guess the object relationships should go like this:

XfmediaApplication

XfmediaPlayer

  • XfmediaXine XfmediaMainWindow

    • XfmediaInfobar
    • XfmediaPlaylist
    • XfmediaPlaylistQueue
  • XfmediaVideoWindow

  • XfmediaTrayIcon (?)

There will be only one XfmediaApplication per process, and this can be considered as a pseudo-global. The various XfmediaPlugin objects (one per plugin) will live as sort of a peer to XfmediaPlayer, and can (obviously) control playback, and probably modify or interact with some parts of the UI. I'll have to be careful to compartmentalise this properly, as I'm sure there are parts of the UI plugins shouldn't be allowed to touch. Fortunately, the XfmediaPlugin object shouldn't have to change, aside from adding new object signals.

There are a few other things that are just floating around.

There's the settings system, which isn't an object at all: just a set of global functions that act on a global settings store. That's definitely a problem if I want multiple xfmedia instances in a single process, since, e.g., you might not want a systray icon for each instance, or you might not want each instance to be sticky on all workspaces. This is going to be a bit of a pain, because all the xfmedia_settings_get_*() calls have only one argument for convenience. Also, when xfmedia exits, which instance gets to write out the settings file? Only the first one? This sounds a bit messy. But supporting multiple settings files for each instance is pretty messy too.

The remote control interface isn't an object either, but it's probably ok (almost) as-is, since it knows how to operate on a specific "session" of xfmedia.

Next we have the keybindings system, which probably needs to be mostly redone. Fortunately it currently acts on a specific XfmediaMainwin instance (which will become XfmediaMainWindow), so it should be relatively easy to modify it to operate on an XfmediaPlayer, and thus be multi-instance-safe. However, all the keybindings are stored in the same file, so I'm not sure it's useful to have separate keybindings for each instance. Also, I'd rather use a standard GTK mechanism for doing keybindings, so I'll probably rethink this at some point (GtkAction?).

The mediamarks editor and menu are keyed to a particular mainwin instance, but, again, I'm not sure it makes sense to make this per-instance. There's only one mediamarks file, supporting more than one in a "smart" manner is pretty difficult, and if you look at them like bookmarks, a web browser doesn't have different bookmarks per window.

The tray icon is something I'm not sure about yet. Having multiple tray icons for each instance sounds a bit silly. I'm thinking about the possibility of a single tray icon being able to control all the instances of xfmedia in the same process. The problem with this approach kinda defeats the purpose of the tray icon: to offer a few simple features of xfmedia just a couple quick mouse clicks away. Increasing the complexity of the tray icon directly contradicts this. At some point I might move the tray icon into a plugin.

Next there's playlist-files.h, which is mainly a set of utility functions for reading and saving various playlist types. It mostly operates on a XfmediaPlaylist instance right now, which I think is fine. The playlist files don't need to know about the player engine at all; they just need to know the contents of the playlist (or just how to load stuff into it).

The "jump to file" box is a bit awkward right now. Originally it was a separate window, but now it's integrated into the XfmediaPlaylist widget. So it's in a separate file, somewhat kludged into playlist.c. This needs to be integrated properly (though it really does work fine as-is) for maintenance's sake.

The last piece is the equaliser window, which I never finished because xine handles EQ in a rather weird way, and I never figured it out well enough to make it work right. I might come back to this at some point, in which case it'll just be a child of XfmediaPlayer, and nobody else needs to know a thing about it, except perhaps how to show and hide it.

A final question is what to do about XfmediaXine: should plugins be able to interact with it directly. I'm thinking no. This allows me to support other playback engines in the future (which probably won't happen, but it's not wise to close the door on the possibility), and helps make sure I've abstracted player details into XfmediaPlayer properly.

So I guess that's about it. Comments? Questions? Not saying I'll listen, but I'm curious to know what people think...

Gaim Not so Fun

A while back, I was interested in hacking on Gaim. I didn't end up doing all that much: I resurrected one of the plugins from the dead, and messed around a bit, but other things (like saving myself from almost failing out of college) got in the way. The one thing I remember is that I never really liked hanging out in #gaim on Freenode. Some of the developers and "crazy patch writers", were, in my limited experience, arrogant assholes (not saying that I don't get that way sometimes, but this was chronic). At the time I was somewhat new to the OSS scene: I had been using OSS for a few years, but I hadn't really gotten too involved in the development side of things, so I didn't think too much of it: maybe that's just how things were "supposed" to be.

And so I stopped hanging out in #gaim. Time passed, and I found an awesome community of OSS developers who were welcoming and friendly, and just thrilled to have extra help. More time passed, and, though I rarely thought about it, I still had a pretty dim view of the Gaim developers.

Today I head over to Planet GNOME, and stumble upon this, and also this. And suddenly I feel validated. It's really sad: Gaim is a very high-profile OSS project, and it's a shame to see that the people behind it can't handle playing nice with each other. And now, with Sean Egan (Gaim lead developer) hired by Google, it seems like Google pretty much owns Gaim. I can certainly understand the lure of a good job with a company like Google, but it looks like a pretty crappy situation.

Ah well. The OSS world tends to route around stupidities. If enough people think Gaim needs to fork, it'll happen. If enough people think we need a new, better-designed IM client, it'll happen. If the current situation works itself out positively, all the better. Only time will tell.

Tablettage

So I finally ordered my Nokia 770 Internet Tablet, with the sweet developer discount. I was a bit afraid I'd been left out when I saw a bunch of other people ordering and receiving theirs. I guess they were just giving out the coupon codes in batches or something.

Anyway, it looks like a really cool device, and I'm looking forward to hacking on it. I was poking around the API documentation for the platform, and it seems like there's a lot to mess around with. The little guy has quite a bit of potential. I've been looking for the chance to cut my teeth on programming for an embedded device, and this looks like the perfect opportunity.

Annoyingly, the only shipping methods were fedex 2nd day, and overnight, and the 2nd day is $15. Lame. And of course that means it'll arrive nice and quickly... and then sit at my rental office for 5 days until I get back from Germany. Figures.

Wizards

Hmm, according to this, I'm a "wizard" at programming. Somehow methinks this dude overestimates the skill required to work with multithreaded apps. I think I'm pretty damned good, but I don't think I'd call myself a wizard. (Not to mention that that'd be pretty presumptuous.)

I also disagree with several of the statements in those slides as to why events are easier to handle than threads. For starters, I'll say that I do agree that locking isn't easy. In more complex cases, it's easy to forget a lock somewhere and get corrupted data, or to mis-design a situation where you can get deadlocks.

However, the statement "with threads, even the simplest application faces the full complexity" is a bit disingenuous. There are several tools available for communication between threads (such as locking queues) that allow a programmer to avoid nasty locking situations. Are they suitable for all situations? No, of course not. But sometimes, with a simpler multithreaded application, you can get away with ignoring mutexes, semaphores, condition variables, etc., depending on how the application works with its data -- or rather, how the application needs to share its data between different threads. Sometimes all that is necessary is to have a single data structure that holds "aggregate" data provided by multiple threads, and in that case all you need is a single mutex to protect that data structure. Sure, there are more complicated examples, but that's just my point: there are varying levels of complexity in multithreaded applications.

I'm also not seeing how the event-driven model is all that easy. It usually requires thinking about your program flow in a completely different manner than if you're using threads. Event-driven apps require asynchronous callbacks, and often a complicated state machine.

A great example of this stems from my work on my mail watcher plugin for the Xfce panel. The original mail checker had a terrible flaw: all network I/O was done synchronously, so any network delays would cause the whole panel to become unresponsive. I considered both solutions to this problem:

  1. Using an event-driven model, single-threaded, with non-blocking network sockets

  2. Using a multithreaded design, one thread per connection, with blocking sockets

Ultimately, I chose the second option. This way, I could have this program flow on checking for new messages:

  1. Convert the server's hostname into an IP address.

  2. Connect to the server.

  3. Do the initial handshaking with the server and authenticate.

  4. Check for new messages.

  5. Log off from the server and disconnect.

With a multithreaded system, I could do all of these in succession, without worrying about blocking. Either each step could complete in the blink of an eye, or it could take 30 seconds for each step. It doesn't matter.

With an event driven system, I'd have to have a state machine with a state for every single time I try to receive data from the network. That means one state each for steps #1 and #2, two to four states for #3, one or two states for each message folder in #4, and at least once state for #5.

I suppose that isn't so terrible, but consider that because of how the C library works, there's no way to make #1 non-blocking. Also, for secure SSL connections, I would probably have to use a more complex interface into the security library I was using to avoid blocking within the library.

So eventually I decided to use threads. In the end, I had a couple small locking problems, which were immediately apparent and not difficult to fix. I don't recall encountering any deadlock situations.

I guess it just really depends on how your mind works best...

Search Strings

So, according to my website stats, these fine search engine strings have been used (among others) in the month of October to find my site:

  • everything is gay

  • bastard

  • academia sucks

Not much terribly interesting for November, except maybe "xray apendicitis" [sic], which is rather odd.

I am amused.

Upcoming Travel

I'm doing a bit more travelling before the year ends.

This Saturday (12 Nov), I'm leaving for Berlin for an Intel thing. I'll be there until the next Saturday morning. I should hopefully have a fair amount of time to do some sightseeing, and I'll be able to see Jens and Moritz while I'm there. Awesome. Malte, from our Munich office should be joining me for a couple days, which will be cool.

In December, I'm going back to the east coast for Christmas and New Year's. Amazingly, I managed to get a free flight with all the miles I've racked up with United this past year. I really thought that entire time period would be blacked out, but I managed to get a flight out on the 24th, and one back on the 4th. Not ideal, but it's free, so I'll take it. I'll probably be up in NYC for a day or two around the 28th or 29th, so if you're in the area, drop me a line. Otherwise I'll be in MD.

« prev 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 next »