Re: [Rhythmbox-devel] Updating to the new last.fm API

[Jonathan Matthew <jonathan d14n org>]

On Mon, Apr 27, 2009 at 08:43:24AM -0400, Matt Novenstern wrote:
> Hi all,
> 
> 	I'm sitting down to update RB to last.fm's new authentication scheme,
> one step of which involves requiring the user to give the program
> permission by logging in through a web page.  So, I can either
> 
> a) Launch an external browser to log in in, or
> 
> b) Try and put a browser somewhere in RB's UI

I'm not really sure what the intent of this step is, exactly, but I'm guessing
the point is to ensure the user agrees to let the app access their last.fm account in
a way that the app can't fake or trick the user into accepting.  If we try to do that 
with an embedded browser, it looks like we're cheating.  I think it'd be much better to 
use the user's default web browser to do this.  Much easier too.

> I wonder if maybe some general browser integration might be a nice
> feature for more plugins than just the last.fm one.  Perhaps having a
> collapsable section at the bottom of the source view?

Embedding a HTML display widget is one thing (we have a SoC project involving that..).
Embedding something that's intended to work like a real browser is much more complicated
and brings in all kinds of UI horrors that we shouldn't try to deal with - I don't know
about anyone else, but I don't feel like reimplementing epiphany inside rhythmbox.

So, my first thoughts on using HTML in rhythmbox: it's fine for displaying complex text 
and image layouts, as long as the structure of the HTML (and CSS etc.) is internally 
defined (passed to the display widget via its API, loaded from a local file, or whatever),
and all links are opened in a real browser.  Text and images can be retrieved externally,
of course.  I'm not sure about external javascript, but it seems like we should avoid
it.