<div class="gmail_quote">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><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#">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>