URL and application handling/registration standard

[Yfrwlf]

Thanks for the help, everyone! 
/home/user/.local/share/applications/mimeapps.list was what I was 
looking for.  I'll try registering new uri types there and test the results.

As for trying to use some logic to test a uri (http://blah.org/pic.png) 
before it is passed off to the default app for that protocol type 
(browser) to see if it could be opened with an image viewer instead, of 
course you could implement that somehow.  Call it a "sniffer 
application" or something, give it a mime type code, and then users can 
use the same methods to disable or change the default sniffer 
application just like with any other mime type if the detection gets too 
far off.  Perhaps if that becomes a popular way to handle uris, programs 
would implement "open with" for all uris as a quick way to bypass the 
sniffer. Say you're in Pidgin and get an IM with a URI, you click on it 
and it opens the wrong app, but it normally opens the preferred app. If 
Pidgin implemented an "open with" to adapt to sniffers, the context menu 
could say "Open with <default sniffer>" and "Open with <default normal 
URI app>".



On 09/29/2012 06:38 PM, Jerome Leclanche wrote:
> 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 
> <mailto:shnatsel at gmail.com>> wrote:
>
>     2012/9/29 Jerome Leclanche <adys.wh at gmail.com
>     <mailto: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/d9ea37a8/attachment-0001.html>