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