<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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.<br>
<br>
As for trying to use some logic to test a uri
(<a class="moz-txt-link-freetext" href="http://blah.org/pic.png">http://blah.org/pic.png</a>) 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>".<br>
<br>
<br>
<br>
On 09/29/2012 06:38 PM, Jerome Leclanche wrote:<br>
</div>
<blockquote
cite="mid:CAFd36BjQDR6yVjxJJOyh6VD6kds+K23eL36MupH4fSp1Gd0pzg@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true" 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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://example.com/foo.png"
target="_blank">http://example.com/foo.png</a>),
but on a practical level, <a class="moz-txt-link-freetext" href="file://">file://</a> 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 <a class="moz-txt-link-freetext" href="http://">http://</a> 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 <a class="moz-txt-link-freetext" href="http://">http://</a> 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 <a class="moz-txt-link-freetext" href="file://">file://</a>
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
moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>