On Sun, 2012-09-30 at 00:38 +0100, 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,
Feel free to read the archives of this mailing-list to know why adding a list of protocols isn't a good idea, and actually harms interoperability. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
