There are a lot of issues with coming up with a good system for this.<div><br></div><div>Say you get a uri to an image: <a href="http://example.com/image.png">http://example.com/image.png</a>. You want that uri to open in an image viewer that supports http.</div>
<div><br></div><div> - 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.</div>
<div> - The reverse has to be supported: <a href="http://example.com/image/?id=12345">http://example.com/image/?id=12345</a>. This cannot be guessed by name, it has to be sniffed. Most likely scenario is it'll get opened in a web browser always.</div>
<div><br></div><div>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, </div>
<div><br></div><div>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?</div>
<div>
<br></div><div>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.</div><div>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.</div>
<div><br></div><div>Better solution yet, imho: Screw being too clever.</div><div> - Have apps list protocols they support. Eg Protocols=x-scheme-handler/http;x-scheme-handler/https;</div><div> - 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.</div>
<div> - 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.</div><div>
<br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br><div>J. Leclanche<br>
<br><br><div class="gmail_quote">On Sat, Sep 29, 2012 at 11:37 PM, Сергей Давыдов <span dir="ltr"><<a href="mailto:shnatsel@gmail.com" target="_blank">shnatsel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>2012/9/29 Jerome Leclanche <span dir="ltr"><<a href="mailto:adys.wh@gmail.com" target="_blank">adys.wh@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>It is up to the implementation to detect the mime type out of that protocol (eg. image/png out of <a href="http://example.com/foo.png" target="_blank">http://example.com/foo.png</a>), 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.<br>
</div></blockquote></div><div><br>You're right at least regarding the practical level; this special-casing exists and it's rather problematic for user experience. <br>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.<br>
<br>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.<br>
<br>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 <a href="https://docs.google.com/document/d/1kfI-JB80egEmix0HIJkDkDtMHGF_xeQMqQANqIxxnlo/edit#" target="_blank">https://docs.google.com/document/d/1kfI-JB80egEmix0HIJkDkDtMHGF_xeQMqQANqIxxnlo/edit#</a>, it's open for commenting and editing.<br>
<br>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.<br><br>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.<br>
<br>--<br>Sergey "Shnatsel" Davidoff<br></div></div>
</blockquote></div><br></div>
</div>