Replacing xdg-open

[Jerome Leclanche]

Alright, I know razor ships its own xdg-open already (not sure on the differences with the regular one), but the fact is: The current implementation of xdg-open sucks.

For those who don't know how xdg-open works: it's an impossibly hacky shell script that detects your desktop environment and attempts to open a file using DE-specific openers such as kde-open, gnome-open etc.

The chromium team added a rough parser for .desktop files in their own shipped xdg-open but it's a sed script.

I'd like to replace it by a clean python script. I found python to be the best choice for this because shell/bash are horrible for the job (proper parsing etc). C wouldn't be a bad choice but who's going to write a proper lib for this?

I found almost every single library out there relies on file / libmagic (including QtXdg!). Those that don't are pure horrible code.

I wrote a python library (no dependencies) for xdg-compliant mime parsing. It supports xdg as a backend so it would technically be possible to add libmagic backend and so on though there is no point in that really.

The only issue is with magicfile parsing (/usr/share/mime/magic), which is still buggy, but I'm working on that (I just don't have too much free time this week).

The xdg backend supports mime type detection by name (globs), stat (inode/*) as well as content (magic, unfinished). It also supports installing xdg mime packages.

In the end, replacing xdg-open with a script like this one would free non-mainstream DEs from that hacky dependency. I'll get to writing it some time next week most likely, I just wanted to gather some opinions first.

[Aaron Lewis]

I think we should wait until the default File Manager is selected , and add a handler of inode/directory

--
You received this message because you are subscribed to the Google
Groups "Razor-qt" group.
For more options, visit this group at
http://groups.google.com/group/razor-qt?hl=en

--

Best Regards,

Aaron Lewis - PGP: 0xDFE6C29E ( http://keyserver.veridis.com )

Finger Print: 9482 448F C7C3 896C 1DFE 7DD3 2492 A7D0 DFE6 C29E

[Jerome Leclanche]

That has little to do with it. xdg-open is used globally by every app that opens generic files.

J. Leclanche

[Александр Соколов]

We distribute these files temporarily. We are trying to push them to upstream. I hope that in the future we don't need to use hacks for the running of programs.

2012/3/2 Jerome Leclanche <ady...@gmail.com>

--
Best regards,
Alexander.

[Alec Moskvin]

It looks to me as if the upstream forgot about them, and the patches
Petr made no longer work against the current version. Maybe remind them
again? (open a bug?)

On Friday 02 March 2012 21:14:38, Александр Соколов wrote:
> We distribute these files temporarily. We are trying to push <http://We
> distribute these files temporarily. We are trying to push them upstream.> them

[Petr Vanek]

On Mar 2, 2012 (Friday), at 6:24 PM, Alec Moskvin wrote:

> It looks to me as if the upstream forgot about them, and the patches
> Petr made no longer work against the current version. Maybe remind them
> again? (open a bug?)

a bug report is there already:
https://bugs.freedesktop.org/show_bug.cgi?id=45295

also bump email has been sent to portland mailing list today.

p.

[Jerome Leclanche]

While improvements to the current xdg-open are great, my proposal was about replacing it by a completely new non-shell script that relies on proper xdg parsing.

J. Leclanche

p.

[Kevin Krammer]

On Friday, 2012-03-02, Jerome Leclanche wrote:
> While improvements to the current xdg-open are great, my proposal was about
> replacing it by a completely new non-shell script that relies on proper xdg
> parsing.

Indeed. Most desktops have a dedicated tool that does that job properly, e.g.
also taking user settings into account.

Speaking as one of the original authors of xdg-open, it is intended as an
adapter, so independent programs have one interface to call.

The original idea of all xdg-utils script was to provide a short term solution
with easy to satisfy (and as little as possible) dependecies until a proper
solution can be reliably be assumed to be present.

Unfortunately that second phase was kind of derailed when money came into play
(some implementations got kickstarted with Linux Foundation money but became
unmaintained after delivery).

The idea was that a desktop specific session service would provide the xdg-
utils functionality through D-Bus interfaces. I think the current state is
that some of the functionality has been implemented that way, e.g. screensaver
inhibition, but others like opening URLs has not.

There might be others as well, I am not following the development closely
enough anymore.

Cheers,
Kevin

>
> J. Leclanche
>
> On Fri, Mar 2, 2012 at 6:03 PM, Petr Vanek <pe...@scribus.info> wrote:
> > On Mar 2, 2012 (Friday), at 6:24 PM, Alec Moskvin wrote:
> > > It looks to me as if the upstream forgot about them, and the patches
> > > Petr made no longer work against the current version. Maybe remind them
> > > again? (open a bug?)
> >
> > a bug report is there already:
> > https://bugs.freedesktop.org/show_bug.cgi?id=45295
> >
> > also bump email has been sent to portland mailing list today.
> >
> > p.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Razor-qt" group.
> > For more options, visit this group at
> > http://groups.google.com/group/razor-qt?hl=en

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

[Jerome Leclanche]

I'm not sure I understand the point of having an adapter anymore. xdg provides both the spec and the utility. What kind of user settings are we talking about?

URI opening has been implemented as a mime type, using x-scheme-handler/http and such.

A further point I wanted to bring up was services. Applications should provide, in their .desktop file, the services they provide. I believe since I mentioned it last, Android got an implementation that follows the same path (using reverse DNS). Brought to the desktop though, the idea would be to have services such as IRC client, Web browser, email client, IM client, window manager, etc.

There is some overlap with x-scheme-handler, but there is indeed a case for it. Window managers for example do not handle URIs and do not have their own schemes, while IM clients would have multiple schemes (xmpp, aim, ...). The hard part is defining the split between the two: I do not think services should try to bind themselves to mime types/uris as it's a can of worms, it's more to be able to make a button that says "Opens your default web browser".

Think of it like you were making an agnostic application launcher.

J. Leclanche

[Kevin Krammer]

On Friday, 2012-03-02, Jerome Leclanche wrote:
> I'm not sure I understand the point of having an adapter anymore. xdg
> provides both the spec and the utility. What kind of user settings are we
> talking about?

Application preference.
For example if you are the developer of a PDF reader you want to be able to
allow user clicks on URLs and they should be opened in the user's preferred
browser.

Or if you are developing an email program an you have attachments, you want to
be able to open them in the preferred application.

> URI opening has been implemented as a mime type, using
> x-scheme-handler/http and such.
>
> A further point I wanted to bring up was services. Applications should
> provide, in their .desktop file, the services they provide. I believe since
> I mentioned it last, Android got an implementation that follows the same
> path (using reverse DNS). Brought to the desktop though, the idea would be
> to have services such as IRC client, Web browser, email client, IM client,
> window manager, etc.
>
> There is some overlap with x-scheme-handler, but there is indeed a case for
> it. Window managers for example do not handle URIs and do not have their
> own schemes, while IM clients would have multiple schemes (xmpp, aim, ...).
> The hard part is defining the split between the two: I do not think
> services should try to bind themselves to mime types/uris as it's a can of
> worms, it's more to be able to make a button that says "Opens your default
> web browser".

The potential service I wrote about would not associate itself with any MIME
type or URI scheme, it would provide an implementation for an API application
developers can delegate launching to.

Of course, ideally there would be only one such implementation, shared between
all workspace implementations.
I haven't checked respective specifications for quite some time, last time I
did user preference were still highly desktop dependent (e.g. GNOME storing
them very differently than KDE, and so on).

If there is already an accepted specification for this, then it would probably
be best (for compatibility) to implement xdg-open such that it uses that
information directly instead of delegating to desktop specific helpers.

Cheers,
Kevin

[Jerome Leclanche]

Applications' .desktop files store the mime types they are able to read and wish to open. If you develop a pdf reader and want to click links, my version of xdg-open would see it's an url and look for an app that binds x-scheme-handler/http. Same deal with an email client: xdg-open would look at the file's mime type and look for a .desktop file binding it.

There is no need to go through DE-specific user settings as those .desktop / mimetype bindings are defined by the XDG spec (and gnome/kde respect them).

J. Leclanche

[Kevin Krammer]

On Friday, 2012-03-02, Jerome Leclanche wrote:
> Applications' .desktop files store the mime types they are able to read and
> wish to open.

Yes, I knew that :)

> If you develop a pdf reader and want to click links, my
> version of xdg-open would see it's an url and look for an app that binds
> x-scheme-handler/http.

Right. So I have Konqueror and Firefox installed. How do you decide which one
to launch?

> Same deal with an email client: xdg-open would look
> at the file's mime type and look for a .desktop file binding it.
>
> There is no need to go through DE-specific user settings as those .desktop
> / mimetype bindings are defined by the XDG spec (and gnome/kde respect
> them).

I know, I was talking about user preference, not capability.

So, given multiple applications capable of opening a given MIME type, how does
your implementation of xdg-open know which one to use?

[Jerome Leclanche]

That is controlled by mimeapps.list + mimeinfo.cache. For example, in mine:

text/html=google-chrome.desktop;chromium-devel.desktop;wine-extension-htm.desktop;

smplayer2 would be picked first. This is my implementation:

https://github.com/Adys/python-mime/blob/master/mime/xdg/actions.py#L102

mimeapps.list can be customized by the DE, xdg would check that one. The list is parsed in order, if any doesn't exist, it's skipped.

mimeinfo.cache is generated by update-desktop-database.

IIRC it goes like this, skipping missing ones at any time:

For every xdg dir:

 * Check mimeapps.list.

    - Look in Default Applications first; if found, use that.

    - Look in Added Associations. If any matches, pick the first valid one on the list. If none found, exit, but keep track of Removed Associations

For every xdg dir:

 * Check mimeinfo.cache

    - Look for the mime type; if found, pick the first valid one on the list while ignoring any match from Removed Associations.

Any of these items have an exit point to an application. If it doesn't exit by the end of it, the app is not found.

J. Leclanche

[Petr Vanek]

at first: our patches are in upstream now.

On Mar 2, 2012 (Friday), at 7:09 PM, Jerome Leclanche wrote:

> While improvements to the current xdg-open are great, my proposal was about replacing it by a completely new non-shell script that relies on proper xdg parsing.

we have to take care about xdg-tools. Mainly because Qt uses it internally to open URLs with QDesktopServices.

[Kevin Krammer]

On Saturday, 2012-03-03, Jerome Leclanche wrote:
> That is controlled by mimeapps.list + mimeinfo.cache. For example, in mine:
>
> text/html=google-chrome.desktop;chromium-devel.desktop;wine-extension-htm.d
> esktop;

Ah, interesting. Didn't know there was a spec covering this part. Is this an
extension of the desktop-entry spec or a new one?

> mimeapps.list can be customized by the DE, xdg would check that one. The
> list is parsed in order, if any doesn't exist, it's skipped.
> mimeinfo.cache is generated by update-desktop-database.

Hmm, I have a fairly up-to-date Debian/unstable system but I don't have any
mimeinfo.cache or update-desktop-database. Which package should those be
coming from?

Looks promising, however I am entirely sure this will cover all cases.
I found one mimeapps.list file on my system (in
$HOME/.local/share/applications) but it only contains very few entries.
For example it does not contain any entry for image/jpeg and I definitely have
multiple programs installed which are capable for opening that type.
Yet when I click on such a file it always opens one specific program.

Cheers,
Kevin

[Jerome Leclanche]

update-desktop-database is shipped in desktop-file-utils. I don't believe it's all that widely used though as gnome-open / kde-open implement their own caching algorithm probably.

mimeapps.list comes in *addition* to .desktop files, as it is the file that is supposed to define your custom assignments (for example: I want to assign image/jpeg to google-chrome even though none of its .desktop files specify it). You can also specify, in it, the desktop files you do NOT want associated with a mime type, even though they are (eg. I do not want google-chrome.desktop to be associated with application/pdf, even though it is).

J. Leclanche

[Kevin Krammer]

On Monday, 2012-03-05, Jerome Leclanche wrote:
> update-desktop-database is shipped in desktop-file-utils. I don't believe
> it's all that widely used though as gnome-open / kde-open implement their
> own caching algorithm probably.

I see. I don't have desktop-file-utils installed so it is not a dependency of
anything. Very likely because of separate caching as you say.

> mimeapps.list comes in *addition* to .desktop files, as it is the file that
> is supposed to define your custom assignments (for example: I want to
> assign image/jpeg to google-chrome even though none of its .desktop files
> specify it). You can also specify, in it, the desktop files you do NOT want
> associated with a mime type, even though they are (eg. I do not want
> google-chrome.desktop to be associated with application/pdf, even though it
> is).

So this is more a way to change the information provided by .desktop files
without changing those files directly?

Since I have multiple applications capable of reading image/jpeg according to
their .desktop files, shouldn't there be an entry "removing" that information
for all but one?

When I grep through /usr/share/applications and its subdirectories for
image/jpeg I get four hits:
iceweasel.desktop, gwenview.desktop, okularApplication_kimgio.desktop and
gimp.desktop

I have no image/jpeg entry in mimeapps.list

Yet, when I click any JPEG image in my filemanager or email program or run xdg-
open on such a file they *always* opens in Gwenview.

In your implementation would that be the return value of
ACTIONS.defaultApplication(mime)?

Cheers,
Kevin

>
>
> J. Leclanche
>

[Jerome Leclanche]

On Mon, Mar 5, 2012 at 7:40 PM, Kevin Krammer <anda...@gmail.com> wrote:

On Monday, 2012-03-05, Jerome Leclanche wrote:
> update-desktop-database is shipped in desktop-file-utils. I don't believe
> it's all that widely used though as gnome-open / kde-open implement their
> own caching algorithm probably.

I see. I don't have desktop-file-utils installed so it is not a dependency of
anything. Very likely because of separate caching as you say.

> mimeapps.list comes in *addition* to .desktop files, as it is the file that
> is supposed to define your custom assignments (for example: I want to
> assign image/jpeg to google-chrome even though none of its .desktop files
> specify it). You can also specify, in it, the desktop files you do NOT want
> associated with a mime type, even though they are (eg. I do not want
> google-chrome.desktop to be associated with application/pdf, even though it
> is).

So this is more a way to change the information provided by .desktop files
without changing those files directly?

Since I have multiple applications capable of reading image/jpeg according to
their .desktop files, shouldn't there be an entry "removing" that information
for all but one?

No. Removing entries is only necessary if you *never* want to open a file with the given app; eg act as if it was never defined in the MimeType key of the desktop file. By default, it's left alone and the implementation somehow finds a default app out of all the given ones, taking in account user-customized re-ordering (through mimeapps.list), if any.

 

When I grep through /usr/share/applications and its subdirectories for
image/jpeg I get four hits:
iceweasel.desktop, gwenview.desktop, okularApplication_kimgio.desktop and
gimp.desktop

I have no image/jpeg entry in mimeapps.list

Yet, when I click any JPEG image in my filemanager or email program or run xdg-
open on such a file they *always* opens in Gwenview.

In your implementation would that be the return value of
ACTIONS.defaultApplication(mime)?

My implementation only reads from mimeapps.list and mimecache.info, it does not build its own ordering by parsing desktop files one by one. That is defined in mimecache.info and it relies on update-desktop-database to generate that. If u-d-d decides that gwenview must be first, then it'll be the default output indeed. (Or if it's second and the first one does not exist. I have a feeling it's done alphabetically...)

[Kevin Krammer]

On Monday, 2012-03-05, Jerome Leclanche wrote:
> On Mon, Mar 5, 2012 at 7:40 PM, Kevin Krammer <anda...@gmail.com> wrote:

> > Since I have multiple applications capable of reading image/jpeg
> > according to
> > their .desktop files, shouldn't there be an entry "removing" that
> > information
> > for all but one?
>
> No. Removing entries is only necessary if you *never* want to open a file
> with the given app; eg act as if it was never defined in the MimeType key
> of the desktop file.

I see, thanks for clarifying.

> > When I grep through /usr/share/applications and its subdirectories for
> > image/jpeg I get four hits:
> > iceweasel.desktop, gwenview.desktop, okularApplication_kimgio.desktop and
> > gimp.desktop
> >
> > I have no image/jpeg entry in mimeapps.list
> >
> > Yet, when I click any JPEG image in my filemanager or email program or
> > run xdg-
> > open on such a file they *always* opens in Gwenview.
> >
> > In your implementation would that be the return value of
> > ACTIONS.defaultApplication(mime)?
>
> My implementation only reads from mimeapps.list and mimecache.info, it does
> not build its own ordering by parsing desktop files one by one. That is
> defined in mimecache.info and it relies on update-desktop-database to
> generate that. If u-d-d decides that gwenview must be first, then it'll be
> the default output indeed. (Or if it's second and the first one does not
> exist. I have a feeling it's done alphabetically...)

Hmm, I am not convinced. gwenview.desktop is not the first one alphabetically
(gimp.desktop is), I don't have any mimecache.info (due to not having update-
desktop-database) and I don't have any entry for image/jpeg in mimeapps.list

But I guess the best way is to run the script you are proposing as an xdg-open
replacement and check that it indeed behaves like xdg-open.
If I clone the repository from github, which script to I invoke? Do I have to
set some environment variable or install somewhere?

Cheers,
Kevin

[Jerome Leclanche]

I just noticed I was missing some functionality in the actions module. I will implement it now and push it asap.

To install it, just run ./setup.py build && sudo ./setup.py install. Then you can invoke it with python >>> import mime

J. Leclanche

[Jerome Leclanche]

Ah, I was misunderstanding my own code, I actually implemented what I thought I didn't.

So, if you want to check actions out, you can do something like:

python -c "import mime; print mime.MimeType('image/jpeg').bestApplication()".

bestApplication() will return the desktop file that is best suited to open the mime type according to the spec

defaultApplication() will return the application set to open the mime type by default (in mimeapps.list) if any. It's used by bestApplication if it returns anything.

associations() will return the list of desktop associations with the mime type.

Best way to use it is:

% python -c "import mime; print mime.MimeType.fromName('thisfile.txt').bestApplication()"

juffed.desktop

J. Leclanche

[Kevin Krammer]

Awesome, thanks!

Will test tomorrow.

Cheers,
Kevin

[Jerome Leclanche]

I updated python-mime and added a basic README.

To be entirely honest, I don't know how much of all this is part of the spec. I know mimeinfo.cache is not part of the spec, for one thing. The mime-actions spec is still a draft and hasn't been touched for years; now that I have a decent implementation it would be nice to contact the portland guys and finish up the spec following that implementation (modifying bits if necessary).

I found that, as far as I tested, my implementation covers all use cases you could expect of mime->application associations:

 - Global associations/exclusions

 - Local associations/exclusions

 - Global and local "default application" (I have to say I don't fully understand the point of this. It supersedes all associations, but what do you do when you have two applications trying to set themselves as default app? I suppose you completely override the other one actually... hm... maybe a non-issue)

 - Association ordering by user preference

To define:

 - Behaviour when you have a key both in Removed Associations and Added Associations

   * Proposed: Ignore the exclusion. That way, exclusions are *only* tracked in mimeinfo.cache.

 - Behaviour when you have multiple identical keys within a single mime type (both associations and exclusions).

   * Proposed: Only take first match into account.

J. Leclanche

[Kevin Krammer]

Hi,

didn't have time to test yet but I guess there is currently still a difference
in behavior due to not everything being specified yet and thus unlikely
implemented uniformly enough.

I just wanted to point out that in order for the spec to move forward you'll
have to contact the main xdg mailinglist. The Portland project is at this
stage only one implementor or user of certain specs.
In order for any spec to succeed it needs support from "the big guys" (at
least GNOME and KDE) and discussions for that happen on the main
freedesktop.org list.

[Jerome Leclanche]

I believe it's more or less what KDE and Gnome already do, so this should not be an issue. I'll see about emailing the xdg list about it.

J. Leclanche