unity-design team mailing list archive

[Luke Benstead <kazade@xxxxxxxxx>]

Hi Jeremy,

I think trying to *fix* this situation would be potentially very hard, if
not impossible, to do robustly and correctly. Of course, the reason that
clicking a link opens the web browser is that the browser handles the
http:// protocol, just as it may also handle https:// ftp:// and potentially
others.

Say for example we changed this to what you suggest, and that clicking an
http:// or ftp:// link would first grab the file header, read the mime-type,
and then open the correctly assigned application, what would control the
download process? It's not a simple as just opening it, obviously if the
file was very large, or the connection very slow, there would need to be
some way to cancel the action. So we'd likely need an application for that,
perhaps we can use gvfs and Gnome's built in download manager. But this
still blurs the line of what should be handling what. I assume that if you
were browsing using the web browser, then the browser would have the
opportunity to handle the mime type first before passing it onto the system,
otherwise the Internet just wouldn't work.

I'd argue that we are looking to fix this in the wrong place, really we
should be fixing this in the browser. The web browser is already set up to
consistently handle the protocols assigned with it (along with detecting
unsafe sites, invalid SSL certificates etc.) The only problem is that the
browser is opening up an entire instance (or new tab/window) to download the
file; this is totally unnecessary.

It would be far simpler, more robust, and more cross-desktop compatible to
fix the browser so that it checks the mime-type first before opening a
window, if it's not a mime-type it can handle it should popup the open/save
dialog only. Everything from that point on would behave as it currently
does, with the exception that if the browser process had only spawned to
download that file, then it would exit and if that was the case, there never
would have been a browser window open, just the open/save dialog and the
download dialog.

Luke.


On 3 June 2010 18:24, Jeremy Nickurak <jeremy@xxxxxxxxxxx> wrote:

> Here's a UI experience pet peeve I'd be curious to hear some feedback
> about, especially with regards to whether it's confusing/unintuitive to a
> regular user:
>
> You're in an application, maybe an email client, or an IM conversation, or
> (heaven-forbid) a terminal. There's a URL you'd like to click on, that goes
> to a PDF, .zip archive, or any other file that's not actually going to be
> viewable in a web browser. You click it.
>
> What should happen? It'd be nice to see the content open up in the correct
> application. We have application and content preferences for this sort of
> thing. We can look at mime times, in particular.
>
> What happens? A web browser window opens, with no content, and then the WEB
> BROWSER opens the http connection to the content you asked for, and then
> downloads it or streams it to another application.
>
> Is this by design? Or would it make more sense for the desktop to poke the
> web server, get the mime-type of the content, and then open the relevant
> app? The desktop could even download the content, and continue streaming it
> to the application...
>
> There's a catch that this requires 2 http connections, one to check the
> type of the content, and then one to open it. However, I'd argue that this
> type of interaction isn't going to be making so many connections that that
> would be a bottleneck in any way, or even likely a noticable delay in most
> cases (certainly not more than the delay of opening a web browser window).
> If it was critical, the double-connection issues could be addressed with a
> little clever proxy work...
>
> Thoughts?
>
> --
> Jeremy Nickurak -= Email/XMPP: jeremy@xxxxxxxxxxx =-
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana<https://launchpad.net/%7Eayatana>
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana<https://launchpad.net/%7Eayatana>
> More help   : https://help.launchpad.net/ListHelp
>
>