Re: [Rhythmbox-devel] Rhythmbox: Improved Last.fm Plugin - Weekly Report 1

[Jamie Nicol <jamie thenicols net>]

On Thu, 2010-06-03 at 13:53 +0100, Bastien Nocera wrote:
> On Thu, 2010-06-03 at 12:15 +0100, Jamie Nicol wrote:
> > On Wed, 2010-06-02 at 22:45 +0200, Gilles Dartiguelongue wrote:
> > > about that, please check for the "[Rhythmbox-devel] Updating to the new
> > > last.fm API" thread in the archives of the mailing list. As my first
> > > mail seems to have disappeared before it was sent by my mailer, I wanted
> > > to restate that embedding a web interface in a desktop application for
> > > something like this just doesn't feel right and I would rather stop
> > > using Last.fm plugin altogether that to have to endure the pain of such
> > > integration.
> > > 
> > 
> > After experimenting with both options, I feel I agree with you. There
> > are pros and cons to both. By embedding the browser there is no chance
> > of the user not seeing the page being opened, which is good. But it
> > leads to an awful mess. The user can then navigate to other pages from
> > within rhythmbox, which just doesn't seem right.
> 
> You can block those, or rework the stylesheets to do that. A lot of
> applications use this model, such as Twitterific on iDevices, or even
> the facebook apps on the same devices (and I guess on Android as well).

Having had basically no previous experience using webkit I was not aware
of all the things that could be done with it. :) I spent most of today
learning how to use our own stylesheet and how to block webkit from
going to certain pages, and actually implementing the login with an
embedded webkitgtk widget. Despite being much better than embedding
without doing such things, I still do not feel it is satisfactory.

Using stylesheets I was able to hide almost everything besides the
username and password forms. They do, however, share a div with "Forgot
your password" and "Sign up for an account" links. I'm not particularly
competent with html/css, so I may be missing something here. But I don't
know how these could be hidden without hiding *all* anchors in the
stylesheet, but that would leave random bits of text and look silly.
Simply leaving the links present but blocking them from taking the user
anywhere seems wrong and unintuitive from the user's point of view.

But more importantly, I feel the user *should* be able to click these
links. Needing to sign up for an account or needing a password reminder
is a genuine use-case. And allowing them to do so from within rhythmbox
is not an option without exposing the entire internet to them.

> > So unless anybody else feels this is a mistake, I'm going to make it
> > open in an external web browser. I'll listen to any arguments anyone has
> > about this, and I'm open to persuasion, but currently I feel this is the
> > better option.
> 
> As I mentioned, it probably makes the workflow better to open it
> embedded inside Rhythmbox, and that's a workflow that would probably be
> useful for other sources as well.

I'm not convinced that it does in this case. If it were to work
perfectly, then sure. But if a user does need a password reminder or to
sign up for an account it seems it would make the workflow worse. They
would be taken to this page from within rhythmbox, but then have to open
up their own browser to create an account. Then go back and login from
within rhythmbox. In any case, it should be a rare enough situation
that, unless the workflow is absolutely horrible (and I don't think
opening a web browser is too bad), it shouldn't matter too much. 

I hope I have explained my points well enough. There just seems to be
too many complications and problems with it. I'm definitely feeling
embedding the web page would be more trouble than it's worth.

Cheers