Re: [Rhythmbox-devel] Ideas and thoughts

[Jonathan Matthew <jonathan kaolin hn org>]

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