URL and application handling/registration standard

Jerome Leclanche adys.wh at gmail.com
Sat Sep 29 12:29:31 PDT 2012


A protocol has a mime type: x-scheme-handler/<protocol>. 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 <yfrwlf at gmail.com> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20120929/131c577b/attachment.html>


More information about the xdg mailing list