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, Сергей Давыдов <[email protected]
<mailto:[email protected]>> wrote:
2012/9/29 Jerome Leclanche <[email protected]
<mailto:[email protected]>>
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
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
