On Sun, Jun 12, 2005 at 03:14:24AM +1000, James Livingston wrote: > DAAP aka iTunes music sharing: > > On the client side (playing music from DAAP shares) there is libopendaap > which would do most of the work for us. The big question is whether to > use it directly; [0] has the beginnings of a gnome-vfs wrapper for it. > Personally I think that using it via gnome-vfs wouldn't work to well; as > it would hide away a head of information that would be useful, and make > monitoring for changes harder.
I've had a bit of a look at this, and I thought that a gnome-vfs module wasn't the right approach. DAAP isn't a file system, and treating it as one only provides half an abstraction. Applications still have to have DAAP-specific knowledge to be able to use DAAP shares anyway. I also didn't like libopendaap all that much, since it's got so much of its own infrastructure (IO loop, HTTP client, etc. - why do people keep writing this code? It's no fun.); it stores a copy of the DAAP database itself, regardless of whether an application would find that useful (rhythmbox wouldn't); and I don't think DNS-SD should be integrated at that level, since any other music sharing protocol that used it would have to have its own implementation. I started on a more glib-friendly DAAP client a while ago, but stopped when I found more immediately useful things to work on. I'm not really sure where I got up to with this. > Libopendaap gives the files to us through a file descriptor (pipe), > playbin can use these (via a fd:// URI) in versions 0.8.10 or higher of > GStreamer. It'd be much more useful if it'd just give us HTTP URLs and a means of calculating the magical junk iTunes expects in the HTTP header. > [...] > > Visualisation: > > When using the PlayBin element supporting visualisation is fairly > trivial - I hacked up something that pops up a visualisation window in > about 10 lines of code. The problem is to decide on how it fits into RB. With roughly the same amount of code (well, less than an order of magnitude more..) I've experimentally replaced rb-player with bacon-video-widget from totem. I didn't see the point in keeping rb-player as an abstraction, since bacon-video-widget already does that more successfully. Using bacon-video-widget makes visualisation as simple as sticking the b-v-w instance somewhere in the UI. Sort of. For anyone drooling over projectM screenshots, I should point out that the GStreamer libvisual element doesn't work with OpenGL-based actors such as projectM yet. Eyecandy potential is somewhat limited. > The obvious UI would be to have it show up somewhere in the main window > (although I'm sure we don't need another sidebar widget), and respond to > clicks by becoming full-screen. One thing that I think would be nice > (for people with two monitors) it to be able to have it full-screen on > the second monitor, while having the RB window still there on the first. The obvious UI to me is just a menu item/key shortcut that starts full-screen visualisation, since that's all I ever want. It's simple, and it immediately solves the "how do I make this bigger and get rid of all those stupid widgets?" problems I have with everything else. Of course, if people want a small amount of distracting colour and movement on their screen while they're working in another window, who am I to argue? > Also what kind of options to show to the user is another thing we need > to think on: resolution, which visualisation(s) to use, etc. Overlaying > song metadata is always good. I think bacon-video-widget already solves a lot of this, since it has existing settings for visualisation size/framerate, and element selection. It doesn't do text overlay, though. -jonathan _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
