Re: [Rhythmbox-devel] DACP (iTunes remote) support added

[Peter <rhythmbox-devel maubp freeserve co uk>]

On Sat, Oct 23, 2010 at 2:43 AM, Jonathan Matthew wrote:
>
> On Thu, Oct 21, 2010 at 9:44 AM, Peter wrote:
>> Does this version dependency need to be checked in the RB
>> configure script?
>
> libdmapsharing should probably complain if libsoup isn't new enough
> for DACP to work. It's not really up to an application to check
> versions of libraries required for other libraries to work.

Understood: RB (optionally) depends on libdmapsharing which depends
on libsoup, so it is down to libdmapsharing to check for/require a recent
version of libsoup. Over to you Michael?

On Thu, Oct 21, 2010 at 9:44 AM, Peter wrote:
>> Problems or missing features so far:
>>
>> * Pairing is pretty slick - nicely done. Is it possible to give the pin code
>> focus automatically though? I click on the remote but typing shows some
>> funny little box at the bottom of the screen...
>
> Yes, that seems like a good idea. One way to do this would be to
> override the impl_activate method in rb-dacp-source.c. This is called
> when the user selects the source from the source list.

Over to you Alexandre?

> The funny little box you're seeing is the type-ahead search box for
> the source list, by the way.

I thought it was something search related - thanks for the clarification.

>> * No artwork sent to iPod, although RB seems to understand the request
>> the log claims "No artwork for currently playing song" (which is wrong).
>
> It shouldn't be hard to implement this. If you're interested in
> working on it, take a look at how the status icon plugin deals with
> cover art images.

The DACP plugin will need to access both the currently playing
cover art, and also arbitrary album covers for when browsing
on the iPod/iPhone remote. We will also need to be able to
rescale (shrink) the image, and encode it as PNG to send to
the remote. Clearly it would be best to use the same library
for this as already used elsewhere in RB... I'd have to check.

>> I'm not promising anything, but would patches via a public
>> git repository be welcome (I'm thinking github), or would you
>> like patches via bug reports?
>
> Generally I prefer dealing with patches in bugzilla, but if you wanted
> to point to a branch in a public git repo instead of attaching
> patches, that could possibly work too.

OK.

Thanks,

Peter