URL and application handling/registration standard

[Jerome Leclanche]

There are a lot of issues with coming up with a good system for this.

Say you get a uri to an image: http://example.com/image.png. You want that
uri to open in an image viewer that supports http.

 - What happens if the uri isn't an image? It should instead be opened in a
browser. But xdg-open cannot know how to open and sniff arbitrary
protocols, so it either has to open in an http reader *first* that then
forwards it to an image viewer, or the image viewer has to understand a lot
more about the protocol than might be implemented. Confusion can arise if
the image format is not supported by the image viewer, too (but still
registered); it would forward back and forth between browser and image
viewer.
 - The reverse has to be supported: http://example.com/image/?id=12345.
This cannot be guessed by name, it has to be sniffed. Most likely scenario
is it'll get opened in a web browser always.

This is just for http; some protocols are much more obscure about all this.
And you have to remember not to go overboard when "integrating" it, for
users will likely want to disable this behaviour (and always open such and
such protocol in a specific program,

Now the question becomes: How can you open an arbitrary uri in an arbitrary
program that supports the uri's protocol, without breaking everything or
having to fire 2-3 programs successively?

A start is to flag a protocol as an interface to files. irc:// protocol for
example doesn't present any file, so we should never try to be clever about
it.
Afterwards, the content type has to be figured out. For http it's easy, for
say ssh not so much. Once you have a connection, you'll want to keep it
open. So ideally the same program handles the connection and the reading.
This conflicts with supporting arbitrary uris: you cannot know in advance
the mime type.

Better solution yet, imho: Screw being too clever.
 - Have apps list protocols they support. Eg
Protocols=x-scheme-handler/http;x-scheme-handler/https;
 - If you have a link to an image.png in a browser, the browser may
implement a context menu with "Open in... eog, feh". If this action breaks,
the user will know why at least as they have initiated the action. Browser
may yet be even more clever and send a HEAD to check the content type (for
http), these are implementation details.
 - If you right click an already-opened image, browser may show "Open in...
eog, feh" if it so desires. Arbitrary uris would only be supported that
way... it doesn't really get better than this.

If such behaviour was to take form, there would be implementation left
(majorly) to web browsers. However, one identical point keeps coming up in
all and any proposal ive seen for this: Applications need a way to describe
what protocols they support. Most DEs have a vendor prefixed key for that.

For that reason alone I would be in favour of recommending adding an
official, yet unused Protocols key to .desktop files, that would list
protocols a program is able to deal with if given a link to *content*
through it. If fdo ever gets around to having a real spec for all this,
that large part of the work will have already been done.

J. Leclanche


On Sat, Sep 29, 2012 at 11:37 PM, Сергей Давыдов <shnatsel at gmail.com> wrote:

> 2012/9/29 Jerome Leclanche <adys.wh at gmail.com>
>
>> It is up to the implementation to detect the mime type out of that
>> protocol (eg. image/png out of http://example.com/foo.png), but on a
>> practical level, file:// is special-cased to detect the mime type, and the
>> rest is usually left to DEs with things like KIO and such. Correct me if
>> I'm wrong on this one.
>>
>
> You're right at least regarding the practical level; this special-casing
> exists and it's rather problematic for user experience.
> Right now all http:// goes to web browsers and all kinds of mime types
> end up being displayed in the web browser; for example, I'm forced to view
> all pictures that people share with me in the browser even though EOG is
> perfectly capable of handling http:// downloads and is much more suitable
> for viewing images.
>
> If the web browser doesn't support the given format, the situation is even
> worse; the user is presented a choice: either to open the file right away
> and never see it again, or to save the file for future use but not open it
> right away. What if the user prefers to view the file first and then decide
> if it's worth saving for later? I bet that's the most common use case.
>
> I've realized this a few week ago and came up with a proposal on fixing
> that. The basic idea is extending mimetype detection to protocols other
> than file:// with a smooth transition from the current state. I've proposed
> it to elementary project and got a green light on the basic direction from
> their user experience team, so at least one party interested. The current
> draft can be found at
> https://docs.google.com/document/d/1kfI-JB80egEmix0HIJkDkDtMHGF_xeQMqQANqIxxnlo/edit#,
> it's open for commenting and editing.
>
> This problem is no way exclusive to elementary and I believe other
> parties/DEs would be interested in fixing this too. I wonder what the
> proper way of contacting developers/designers of other DEs is.
>
> Also, a smooth transition from the current situation will require adding
> one or several new keys in .desktop file; how do I request that? elementary
> could just add X-elementary-* fields but I believe this should not be
> DE-specific.
>
> --
> Sergey "Shnatsel" Davidoff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20120930/e83a1640/attachment.html>