Re: URL and application handling/registration standard

2012-10-22 Thread Bastien Nocera 
On Mon, 2012-10-22 at 10:30 +0200, David Faure wrote:
> On Monday 22 October 2012 09:45:31 Bastien Nocera wrote:
> > On Sun, 2012-10-21 at 22:58 +0200, David Faure wrote:
> > > On Friday 19 October 2012 17:09:50 David Faure wrote:
> > > > > Better solution yet, imho: Screw being too clever.
> > > > > 
> > > > >  - Have apps list protocols they support. Eg
> > > > > 
> > > > > Protocols=x-scheme-handler/http;x-scheme-handler/https;
> > > > 
> > > > Never ever do this, for the reasons above. HTTP is too complex to send
> > > > all
> > > > http urls to a single app.
> > > 
> > > Ouch, and I just found out that /usr/share/applications/firefox.desktop
> > > says
> > > 
> > > MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.
> > > xul+xml;text/mml;application/x-
> > > xpinstall;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/f
> > > tp;
> > > 
> > > on OpenSUSE 12.1 at least.
> > > (MozillaFirefox-15.0.1-2.40.1.x86_64)
> > > 
> > > Didn't we say no application should ever associate itself with x-scheme-
> > > handler/http?
> > 
> > That's not what we said. We said that no non-browser applications should
> > do that.
> 
> I don't like it, but it doesn't matter anymore, I have fixed my patch from 
> yesterday so that x-scheme-handler doesn't have priority over KIO protocol 
> handlers, if both exist.

I think that's the wrong way to do it, but your call.

> > > This is supposed to have priority over anything else, right? (i.e. over
> > > the
> > > standard mechanism of launching an app based on the file contents).
> > > That's fine for special protocols (magnet://, telnet:// etc.) but not for
> > > HTTP...
> > 
> > Why not? Sniffing HTTP URLs is completely broken. It breaks one-time
> > URLs.
> 
> Not if you can then give the connexion out to the app which will hande it.
> But yeah this requires that the first and second app use the same VFS.
> 
> However "sending all HTTP URLs to the browser" is broken too - e.g. if it's a 
> .odt you end up launching a browser just to then launch the office 
> application.
> So double-download there too (of the headers at least).

You'll launch the browser, and either it will download the file and pass
it on to your office application, or (better from my point of view), the
preview is handled by within the browser (as it is in a lot of browsers
for PDFs or other types of office documents) and it offers you to
download it.


___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-10-22 Thread David Faure 
On Monday 22 October 2012 09:45:31 Bastien Nocera wrote:
> On Sun, 2012-10-21 at 22:58 +0200, David Faure wrote:
> > On Friday 19 October 2012 17:09:50 David Faure wrote:
> > > > Better solution yet, imho: Screw being too clever.
> > > > 
> > > >  - Have apps list protocols they support. Eg
> > > > 
> > > > Protocols=x-scheme-handler/http;x-scheme-handler/https;
> > > 
> > > Never ever do this, for the reasons above. HTTP is too complex to send
> > > all
> > > http urls to a single app.
> > 
> > Ouch, and I just found out that /usr/share/applications/firefox.desktop
> > says
> > 
> > MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.
> > xul+xml;text/mml;application/x-
> > xpinstall;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/f
> > tp;
> > 
> > on OpenSUSE 12.1 at least.
> > (MozillaFirefox-15.0.1-2.40.1.x86_64)
> > 
> > Didn't we say no application should ever associate itself with x-scheme-
> > handler/http?
> 
> That's not what we said. We said that no non-browser applications should
> do that.

I don't like it, but it doesn't matter anymore, I have fixed my patch from 
yesterday so that x-scheme-handler doesn't have priority over KIO protocol 
handlers, if both exist.

> > This is supposed to have priority over anything else, right? (i.e. over
> > the
> > standard mechanism of launching an app based on the file contents).
> > That's fine for special protocols (magnet://, telnet:// etc.) but not for
> > HTTP...
> 
> Why not? Sniffing HTTP URLs is completely broken. It breaks one-time
> URLs.

Not if you can then give the connexion out to the app which will hande it.
But yeah this requires that the first and second app use the same VFS.

However "sending all HTTP URLs to the browser" is broken too - e.g. if it's a 
.odt you end up launching a browser just to then launch the office application.
So double-download there too (of the headers at least).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-10-22 Thread Bastien Nocera 
On Sun, 2012-10-21 at 22:58 +0200, David Faure wrote:
> On Friday 19 October 2012 17:09:50 David Faure wrote:
> > > Better solution yet, imho: Screw being too clever.
> > >
> > >  - Have apps list protocols they support. Eg
> > >
> > > Protocols=x-scheme-handler/http;x-scheme-handler/https;
> > 
> > Never ever do this, for the reasons above. HTTP is too complex to send all 
> > http urls to a single app.
> 
> Ouch, and I just found out that /usr/share/applications/firefox.desktop says
> 
> MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;application/x-
> xpinstall;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;
> 
> on OpenSUSE 12.1 at least.
> (MozillaFirefox-15.0.1-2.40.1.x86_64)
> 
> Didn't we say no application should ever associate itself with x-scheme-
> handler/http?

That's not what we said. We said that no non-browser applications should
do that.

> This is supposed to have priority over anything else, right? (i.e. over the 
> standard mechanism of launching an app based on the file contents).
> That's fine for special protocols (magnet://, telnet:// etc.) but not for 
> HTTP... 

Why not? Sniffing HTTP URLs is completely broken. It breaks one-time
URLs.

___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-10-21 Thread Jerome Leclanche 
I don't believe that was the case.

chromium.desktop has the
same: 
MimeType=text/html;text/xml;application/xhtml+xml;text/mml;x-scheme-handler/http;x-scheme-handler/https;


J. Leclanche


On Sun, Oct 21, 2012 at 9:58 PM, David Faure  wrote:

> On Friday 19 October 2012 17:09:50 David Faure wrote:
> > > Better solution yet, imho: Screw being too clever.
> > >
> > >  - Have apps list protocols they support. Eg
> > >
> > > Protocols=x-scheme-handler/http;x-scheme-handler/https;
> >
> > Never ever do this, for the reasons above. HTTP is too complex to send
> all
> > http urls to a single app.
>
> Ouch, and I just found out that /usr/share/applications/firefox.desktop
> says
>
>
> MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;application/x-
>
> xpinstall;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;
>
> on OpenSUSE 12.1 at least.
> (MozillaFirefox-15.0.1-2.40.1.x86_64)
>
> Didn't we say no application should ever associate itself with x-scheme-
> handler/http?
> This is supposed to have priority over anything else, right? (i.e. over the
> standard mechanism of launching an app based on the file contents).
> That's fine for special protocols (magnet://, telnet:// etc.) but not for
> HTTP...
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-10-21 Thread David Faure 
On Friday 19 October 2012 17:09:50 David Faure wrote:
> > Better solution yet, imho: Screw being too clever.
> >
> >  - Have apps list protocols they support. Eg
> >
> > Protocols=x-scheme-handler/http;x-scheme-handler/https;
> 
> Never ever do this, for the reasons above. HTTP is too complex to send all 
> http urls to a single app.

Ouch, and I just found out that /usr/share/applications/firefox.desktop says

MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;application/x-
xpinstall;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;

on OpenSUSE 12.1 at least.
(MozillaFirefox-15.0.1-2.40.1.x86_64)

Didn't we say no application should ever associate itself with x-scheme-
handler/http?
This is supposed to have priority over anything else, right? (i.e. over the 
standard mechanism of launching an app based on the file contents).
That's fine for special protocols (magnet://, telnet:// etc.) but not for 
HTTP... 

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-10-19 Thread David Faure 
On Sunday 30 September 2012 00:38:39 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. 

Or xdg-open calls kde-open, which actually "opens and sniffs supported 
protocols" before deciding which application to open the file with.
The browser and the image viewer don't need any special logic for this
(they just open the same URL, and the underlying VFS called KIO is able to 
hand out the same connection to the application).

>  - The reverse has to be supported: http://example.com/image/?id=12345.
> This cannot be guessed by name, it has to be sniffed.

With HTTP you can *never* guess by name.
http://example.com/cgi-bin/script.pl will likely not return a perl script to 
you, despite the apparently-known extension.

> (and always open such and such protocol in a specific program,

*That* is what x-scheme-handler is for. To disable the above per-mimetype 
associations and skip to "always open this protocol with this app".

> 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?

x-scheme-handler/protocol.

> Better solution yet, imho: Screw being too clever.
>  - Have apps list protocols they support. Eg
> Protocols=x-scheme-handler/http;x-scheme-handler/https;

Never ever do this, for the reasons above. HTTP is too complex to send all 
http urls to a single app.

> 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.

Saw that you got a "no" to that. Welcome to the club.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-10-04 Thread Bastien Nocera 
On Wed, 2012-10-03 at 22:04 +0400, Сергей Давыдов wrote:
> 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.
> 
> I've found
> http://lists.freedesktop.org/archives/xdg/2008-June/009720.html thread
> where the discussion just stalled while everybody seemed to agree on
> adding a list of protocols. 
> It was also briefly brought up in 2010:
> http://lists.freedesktop.org/archives/xdg/2010-October/011661.html and
> continued in
> http://lists.freedesktop.org/archives/xdg/2010-November/011679.html +
> follow-ups. Opinions on that thread seem to be mixed.
> 
> The important info I got from there is that on GNOME, XFCE, LXDE etc.
> all apps support any GIO-supported URLs, and that in GNOME's
> experience making the "viewer" apps download the data doesn't work.

This is the mail that I agree with:
http://thread.gmane.org/gmane.comp.freedesktop.xdg/12310/focus=12370
which pretty says "we're not going to be using that in GIO even if it
exists because it's broken in many different ways".

> Is this a bug report?
> 
> No. I assume I have something misconfigured, unless proven
> otherwise :)

OK.


___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-10-03 Thread Сергей Давыдов 
>
> 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.
>

I've found http://lists.freedesktop.org/archives/xdg/2008-June/009720.htmlthread
where the discussion just stalled while everybody seemed to agree on
adding a list of protocols.
It was also briefly brought up in 2010:
http://lists.freedesktop.org/archives/xdg/2010-October/011661.html and
continued in
http://lists.freedesktop.org/archives/xdg/2010-November/011679.html +
follow-ups. Opinions on that thread seem to be mixed.

The important info I got from there is that on GNOME, XFCE, LXDE etc. all
apps support any GIO-supported URLs, and that in GNOME's experience making
the "viewer" apps download the data doesn't work.

Is this a bug report?


No. I assume I have something misconfigured, unless proven otherwise :)

--
Sergey "Shnatsel" Davidoff
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-10-03 Thread Bastien Nocera 
On Tue, 2012-10-02 at 17:44 +0400, Сергей Давыдов wrote:
> Behavior will largely depend on the actual program xdg-open
> delegates to.
> E.g. on KDE the KIO subsystem knows how to determine the MIME
> type of a
> resource and will look up the application associated with it.
> 
> I would guess that this is also true for GNOME and their IO
> framework.
> 
> It is true for GVFS; gvfs-info can detect mimetype of remote files and
> gvfs-mime is supposed to print the application associated with it, but
> the latter didn't work on my system.

Is this a bug report?


___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-10-03 Thread Bastien Nocera 
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
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-10-02 Thread Сергей Давыдов 
>
> Behavior will largely depend on the actual program xdg-open delegates to.
> E.g. on KDE the KIO subsystem knows how to determine the MIME type of a
> resource and will look up the application associated with it.
>
> I would guess that this is also true for GNOME and their IO framework.
>

It is true for GVFS; gvfs-info can detect mimetype of remote files and
gvfs-mime is supposed to print the application associated with it, but the
latter didn't work on my system.

--
Sergey "Shnatsel" Davidoff
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-10-02 Thread Kevin Krammer 
On Sunday, 2012-09-30, Jerome Leclanche wrote:

>  - 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.

Behavior will largely depend on the actual program xdg-open delegates to.
E.g. on KDE the KIO subsystem knows how to determine the MIME type of a 
resource and will look up the application associated with it.

I would guess that this is also true for GNOME and their IO framework.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-09-30 Thread Сергей Давыдов 
> 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.
>

GNOME does not seem to have a key for that; not sure about other DEs.

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.
>

I came up with a solution in which the same program handles the connection
and the reading. Moreover, "viewer" apps only have to deal with local
files, so exporting the list of protocols supported by the app is not
required.

I've added it to the same document, it can be viewed at
https://docs.google.com/document/d/1kfI-JB80egEmix0HIJkDkDtMHGF_xeQMqQANqIxxnlo/edit#heading=h.f9ujrurjty1j

I'm looking forward to any feedback on this draft.

--
Sergey "Shnatsel" Davidoff
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-09-30 Thread Yfrwlf 
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 " and "Open with 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, Сергей Давыдов > wrote:


2012/9/29 Jerome Leclanche mailto:adys...@gmail.com>>

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 ht

Re: URL and application handling/registration standard

2012-09-29 Thread Jerome Leclanche 
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, Сергей Давыдов  wrote:

> 2012/9/29 Jerome Leclanche 
>
>> 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 elementar

Re: URL and application handling/registration standard

2012-09-29 Thread Сергей Давыдов 
2012/9/29 Jerome Leclanche 

> 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
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: URL and application handling/registration standard

2012-09-29 Thread Jerome Leclanche 
xdg-open is the freedesktop utility, equivalent to "open" on osx or "start"
on windows. It's standard, and can open any uri or file according to the
spec.

The specs you're looking for are the Shared Mime Info spec and the Mime
Actions spec. Together, they define:
 - How file types are guessed from file names and contents
 - How applications can register themselves to a specific file type or
protocol
 - How all that can be modified through tools and how to write those tools.

J. Leclanche


On Sat, Sep 29, 2012 at 10:12 PM, Yfrwlf  wrote:

>  Associating programs to file types and protocol URLs cannot be
> completely managed by applications as that would not lead to a smooth and
> unified user experience.  It would also demand that all applications be
> more complicated than necessary and implement their own app chooser for
> each file and protocol type.
>
> Firefox and Midori gave me a useless error page when I tried clicking on
> an unrecognized protocol URL.  I noticed Chromium gave me this though:
>
>
>
> xdg-open?  I assume that is a freedesktop query for Gnome, and not part of
> a DE-wide standard?
>
>
>
>
>
> On 09/29/2012 02:29 PM, Jerome Leclanche wrote:
>
> A protocol has a mime type: x-scheme-handler/. To associate with
> http, you need to associate with the mime type x-scheme-handler/http.
>
>  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.
>
> J. Leclanche
>
>
> On Sat, Sep 29, 2012 at 8:22 PM, Yfrwlf  wrote:
>
>>  The association of applications to file types and URLs are handled in
>> different ways by different desktop environments (DEs) currently.  It is
>> understandable as to how this system evolved, because you want file://to be 
>> associated with Dolphin in KDE, and with Nautilus in Gnome.  However,
>> this leaves programs broken which try to register with specific DEs which
>> the user doesn't use.  Developers  are not able to work with every DE's
>> proprietary registration system because doing so is impossible.  This helps
>> create a detrimental environment for the open source ecosystem.  There
>> should be standards for setting default applications for file and URL
>> handlers if none currently exist, and they need to address the issue of
>> DE-specific needs as well as default settings for all DEs.
>>
>> Does anyone know if such standards exist yet?  If not, we need to create
>> them.  Here is an example of the logic that could be used.  The first two
>> columns specify what application is the *default/primary* application to
>> run when the user calls a certain file or URL type, and the 3rd column
>> gives the corresponding action that should be used to decide which one to
>> run.
>>
>>   DE-Wide DE-Specific
>>  Resulting Selection while running Specific DE
>>  Action upon installing
>>   none specified
>>  none specified prompt user for program or do nothing
>>  Change both DE-Wide and DE-Specific
>>   nautilus
>>  none specified run nautilus
>>  Change only DE-Specific
>>   none specified nautilus
>>  run nautilus
>>  Could prompt user, change DE-Wide
>>   nautilus
>>  dolphin
>>  run dolphin
>>  Could prompt user
>>
>>
>> The "Action upon installing" column refers to when a program is being
>> installed or run for the first time and attempts update the association.
>> If a program finds an existing setting, it could either ask the user if
>> they want to change it or make the change anyway or do nothing.  In turn,
>> that choice could, ideally, depend on a DE or global setting as well so
>> that users could avoid all prompts like that in order to further create a
>> uniform desktop experience.  Regardless, the installer/program would always
>> at least add itself to a list of applications which can be used to handle
>> that file type or URL, so there would be a default app setting and a path
>> to that app as well as a list of all apps capable of handling the request.
>>
>> Examples:
>> When installing applications such as torrent clients, they should
>> register "magnet://" to call them, no matter the DE.
>> When installing web browsers, "url://" should be associated to them, no
>> matter the DE.
>> When installing a chat client, programs should register themselves for
>> each "aim://", "yahoo://", "xmpp://" etc URL type, and possibly prompt user
>> for changing the defaults for those if one already exists.
>>
>> Implementation:
>> What would be the best way to implement this standard?  What existing
>> standards are being used for these types of things, if any?  I know that
>> Gnome has gconf and has what amounts to basically a registry for Gnome, but
>> the problem is that it is just for Gnome and so not a true standard that
>> all DEs and programs can use.  Perhaps if Gnome's registry is done well, a
>> simi

Re: URL and application handling/registration standard

2012-09-29 Thread Yfrwlf 

  
  
Associating programs to file types and protocol URLs cannot be
completely managed by applications as that would not lead to a
smooth and unified user experience.  It would also demand that all
applications be more complicated than necessary and implement their
own app chooser for each file and protocol type.
 
  Firefox and Midori gave me a useless error page when I tried
  clicking on an unrecognized protocol URL.  I noticed Chromium gave
  me this though:
  
  
  
  xdg-open?  I assume that is a freedesktop query for Gnome, and not
  part of a DE-wide standard?
  
  
  
  

  On 09/29/2012 02:29 PM, Jerome Leclanche wrote:


  A protocol has a mime type:
x-scheme-handler/. To associate with http, you
need to associate with the mime type x-scheme-handler/http.


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.
  
J. Leclanche


On Sat, Sep 29, 2012 at 8:22 PM,
  Yfrwlf 
  wrote:
  
 The association
  of applications to file types and URLs are handled in
  different ways by different desktop environments (DEs)
  currently.  It is understandable as to how this system
  evolved, because you want file://
  to be associated with Dolphin in KDE, and with
  Nautilus in Gnome.  However, this leaves programs
  broken which try to register with specific DEs which
  the user doesn't use.  Developers  are not able to
  work with every DE's proprietary registration system
  because doing so is impossible.  This helps create a
  detrimental environment for the open source
  ecosystem.  There should be standards for setting
  default applications for file and URL handlers if none
  currently exist, and they need to address the issue of
  DE-specific needs as well as default settings for all
  DEs.
  
  Does anyone know if such standards exist yet?  If not,
  we need to create them.  Here is an example of the
  logic that could be used.  The first two columns
  specify what application is the default/primary
  application to run when the user calls a certain file
  or URL type, and the 3rd column gives the
  corresponding action that should be used to decide
  which one to run.
  
  

  
DE-Wide
DE-Specific

Resulting
  Selection while running Specific DE

Action upon
  installing

  
  
none specified

none specified
prompt user for program or do
  nothing

Change both DE-Wide and
  DE-Specific

  
  
nautilus

none specified
run nautilus

Change only DE-Specific

  
  
none specified
nautilus

run nautilus

Could prompt user, change
  DE-Wide

  
  
nautilus

dolphin

run dolphin

Could prompt user

  

  
  
  
  The "Action upon installing" column refers to when a
  program is being installed or run for the first time
  and attempt

Re: URL and application handling/registration standard

2012-09-29 Thread Jerome Leclanche 
A protocol has a mime type: x-scheme-handler/. To associate with
http, you need to associate with the mime type x-scheme-handler/http.

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.

J. Leclanche


On Sat, Sep 29, 2012 at 8:22 PM, Yfrwlf  wrote:

>  The association of applications to file types and URLs are handled in
> different ways by different desktop environments (DEs) currently.  It is
> understandable as to how this system evolved, because you want file:// to
> be associated with Dolphin in KDE, and with Nautilus in Gnome.  However,
> this leaves programs broken which try to register with specific DEs which
> the user doesn't use.  Developers  are not able to work with every DE's
> proprietary registration system because doing so is impossible.  This helps
> create a detrimental environment for the open source ecosystem.  There
> should be standards for setting default applications for file and URL
> handlers if none currently exist, and they need to address the issue of
> DE-specific needs as well as default settings for all DEs.
>
> Does anyone know if such standards exist yet?  If not, we need to create
> them.  Here is an example of the logic that could be used.  The first two
> columns specify what application is the *default/primary* application to
> run when the user calls a certain file or URL type, and the 3rd column
> gives the corresponding action that should be used to decide which one to
> run.
>
>   DE-Wide DE-Specific
>  Resulting Selection while running Specific DE
>  Action upon installing
>   none specified
>  none specified prompt user for program or do nothing
>  Change both DE-Wide and DE-Specific
>   nautilus
>  none specified run nautilus
>  Change only DE-Specific
>   none specified nautilus
>  run nautilus
>  Could prompt user, change DE-Wide
>   nautilus
>  dolphin
>  run dolphin
>  Could prompt user
>
>
> The "Action upon installing" column refers to when a program is being
> installed or run for the first time and attempts update the association.
> If a program finds an existing setting, it could either ask the user if
> they want to change it or make the change anyway or do nothing.  In turn,
> that choice could, ideally, depend on a DE or global setting as well so
> that users could avoid all prompts like that in order to further create a
> uniform desktop experience.  Regardless, the installer/program would always
> at least add itself to a list of applications which can be used to handle
> that file type or URL, so there would be a default app setting and a path
> to that app as well as a list of all apps capable of handling the request.
>
> Examples:
> When installing applications such as torrent clients, they should register
> "magnet://" to call them, no matter the DE.
> When installing web browsers, "url://" should be associated to them, no
> matter the DE.
> When installing a chat client, programs should register themselves for
> each "aim://", "yahoo://", "xmpp://" etc URL type, and possibly prompt user
> for changing the defaults for those if one already exists.
>
> Implementation:
> What would be the best way to implement this standard?  What existing
> standards are being used for these types of things, if any?  I know that
> Gnome has gconf and has what amounts to basically a registry for Gnome, but
> the problem is that it is just for Gnome and so not a true standard that
> all DEs and programs can use.  Perhaps if Gnome's registry is done well, a
> similar system could be placed in ~/.config, which seems to be the standard
> for all user configuration data which many apps are currently choosing to
> use.
>
> Thoughts, ideas, and suggestions please!
>
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
>
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

URL and application handling/registration standard

2012-09-29 Thread Yfrwlf 
The association of applications to file types and URLs are handled in 
different ways by different desktop environments (DEs) currently.  It is 
understandable as to how this system evolved, because you want file:// 
to be associated with Dolphin in KDE, and with Nautilus in Gnome.  
However, this leaves programs broken which try to register with specific 
DEs which the user doesn't use. Developers  are not able to work with 
every DE's proprietary registration system because doing so is 
impossible.  This helps create a detrimental environment for the open 
source ecosystem. There should be standards for setting default 
applications for file and URL handlers if none currently exist, and they 
need to address the issue of DE-specific needs as well as default 
settings for all DEs.


Does anyone know if such standards exist yet?  If not, we need to create 
them.  Here is an example of the logic that could be used. The first two 
columns specify what application is the *default/primary* application to 
run when the user calls a certain file or URL type, and the 3rd column 
gives the corresponding action that should be used to decide which one 
to run.


DE-Wide DE-Specific
Resulting Selection while running Specific DE
Action upon installing
none specified
none specified  prompt user for program or do nothing
Change both DE-Wide and DE-Specific
nautilus
none specified  run nautilus
Change only DE-Specific
none specified  nautilus
run nautilus
Could prompt user, change DE-Wide
nautilus
dolphin
run dolphin
Could prompt user



The "Action upon installing" column refers to when a program is being 
installed or run for the first time and attempts update the 
association.  If a program finds an existing setting, it could either 
ask the user if they want to change it or make the change anyway or do 
nothing.  In turn, that choice could, ideally, depend on a DE or global 
setting as well so that users could avoid all prompts like that in order 
to further create a uniform desktop experience.  Regardless, the 
installer/program would always at least add itself to a list of 
applications which can be used to handle that file type or URL, so there 
would be a default app setting and a path to that app as well as a list 
of all apps capable of handling the request.


Examples:
When installing applications such as torrent clients, they should 
register "magnet://" to call them, no matter the DE.
When installing web browsers, "url://" should be associated to them, no 
matter the DE.
When installing a chat client, programs should register themselves for 
each "aim://", "yahoo://", "xmpp://" etc URL type, and possibly prompt 
user for changing the defaults for those if one already exists.


Implementation:
What would be the best way to implement this standard?  What existing 
standards are being used for these types of things, if any?  I know that 
Gnome has gconf and has what amounts to basically a registry for Gnome, 
but the problem is that it is just for Gnome and so not a true standard 
that all DEs and programs can use. Perhaps if Gnome's registry is done 
well, a similar system could be placed in ~/.config, which seems to be 
the standard for all user configuration data which many apps are 
currently choosing to use.


Thoughts, ideas, and suggestions please!
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg