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. _______________________________________________ rhythmbox-devel mailing list rhythmbox-devel@gnome.org http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
