use system-wide filetype scheme

[Liviu Andronic]

Hello
This is something that was evaluated in the past, I think. Currently
the TODO list contains this item:
"interrogate shared-configuration data for more filetype handlers (but
FDO spec is still too immature)"

and if I understand correctly it pertains to the filetype scheme used by emel.

The current filetype scheme, although genuinely flexible, is not
always very practical. Specifically, (1) it does not automatically
update itself when programs are (un-)installed and (2) the defaults
are most of the times unsuited for my user habits, meaning that for
each install on a different system (especially on my friends'
computers) I have to start from scratch customizing the filteypes.
Compared with Thunar and other file managers that use system-wide MIME
types, emel requires a lot of customization before it becomes usable,
and this can easily become a show-stopper to its adoption.

So would there be a way to improve things? Perhaps emel could offer a
compile time option that would switch between its internal filetype
scheme and an external one based on MIME types. Or maybe there is an
elegant way to make coexist both filetype approaches. What do you
think?

Regards
Liviu

[t***@onepost.net]

On Mon, 21 May 2012 17:58:25 +0200

Post by Liviu Andronic
This is something that was evaluated in the past, I think. Currently
"interrogate shared-configuration data for more filetype handlers (but
FDO spec is still too immature)"
and if I understand correctly it pertains to the filetype scheme used by emel.
The current filetype scheme, although genuinely flexible, is not
always very practical. Specifically, (1) it does not automatically
update itself when programs are (un-)installed and (2) the defaults
are most of the times unsuited for my user habits, meaning that for
each install on a different system (especially on my friends'
computers) I have to start from scratch customizing the filteypes.

I recommend using the configure plugin. Export your preferred configuration to some file, import the filetypes data from that file into the configuration for the new installation.

Post by Liviu Andronic
Compared with Thunar and other file managers that use system-wide MIME
types, emel requires a lot of customization before it becomes usable,
and this can easily become a show-stopper to its adoption.
So would there be a way to improve things? Perhaps emel could offer a
compile time option that would switch between its internal filetype
scheme and an external one based on MIME types. Or maybe there is an
elegant way to make coexist both filetype approaches. What do you
think?

At http://www.freedesktop.org/wiki/Specifications/mime-actions-spec, I see "...specification has been finalized ... but no formal spec has been written". Also, for some aspects: "Do not use any of this in implementations at this point". Does somebody have time to figure out what the aggregated ML posts amount to?

Files which can be opened by an application are supposed to be defined in the MimeType key of the .desktop file of the application. The emelFM2 fileypes mechanism, as reflected in the file.<actions> item normally in the e2 context menu, does interrogate available .desktop files. However I've just realised that the approach taken is probably wrong - uses the "Actions" key instead of "MimeType" and "Exec".

Any relevant info from a .desktop file is used to supplement info from the internal filetypes configuration. Such information is placed _after_ anything from the filetypes config i.e. nothing about priorities (identification of which is very desktop-specific).

Regards
Tom

[Liviu Andronic]

Post by t***@onepost.net
I recommend using the configure plugin. Export your preferred configuration to some file, import the filetypes data from that file into the configuration for the new installation.

Yes, this is the way to go, although sometimes it is not an option:
when I don't have the exported config file at hand, when the friends'
system is set up completely differently from mine, etc. And it doesn't
cover new users: for many users the defaults are often likely to be
irrelevant, as in not installed on the system.

Post by t***@onepost.net
At http://www.freedesktop.org/wiki/Specifications/mime-actions-spec, I see "...specification has been finalized ... but no formal spec has been written". Also, for some aspects: "Do not use any of this in implementations at this point".

I guess the MIME types are more widely used than this document---last
edited in 2010---seems to suggest. For example, Xfce has recently
introduced in its 4.10 release a 'MIME-type editor' [1] as part of its
'Settings Manager' [2]. Unfortunately its documentation is not
extensive.
[1] http://docs.xfce.org/xfce/xfce4-settings/mime
[2] http://docs.xfce.org/xfce/xfce4-settings/start

Post by t***@onepost.net
Files which can be opened by an application are supposed to be defined in the MimeType key of the .desktop file of the application. The emelFM2 fileypes mechanism, as reflected in the file.<actions> item normally in the e2 context menu, does interrogate available .desktop files. However I've just realised that the approach taken is probably wrong - uses the "Actions" key instead of "MimeType" and "Exec".

Yes, I think I can confirm this: for example, the file.<actions> for a
music file (.ogg) includes only Muine and XMMS, neither of which are
installed on my system. The many other audio-capable apps---Audacity,
Gnome-MPlayer, Parole, VLC, etc.---are not present in the c-menu. And
I've never bothered to extensively customize it: the times I need to
launch some .flac file from emel I usually use 'Open With', a
suboptimal approach.

Post by t***@onepost.net
Any relevant info from a .desktop file is used to supplement info from the internal filetypes configuration. Such information is placed _after_ anything from the filetypes config i.e. nothing about priorities (identification of which is very desktop-specific).

Assuming that the issue above is fixed and the relevant apps
automatically added to file.<actions>, is there a way to re-order the
resulting mixed list? Moreover, what do you think about adding a
file.<mime-actions>? This way the user has full control over how the
items are displayed, and can put it, say, in a submenu, or first in
the list. Thus with a quick config switch the user would instantly
have an (almost) fully customized filetype scheme.

Regards
Liviu

[t***@onepost.net]

On Wed, 23 May 2012 18:08:22 +1000

Post by t***@onepost.net
Files which can be opened by an application are supposed to be defined in the MimeType key of the .desktop file of the application. The emelFM2 fileypes mechanism, as reflected in the file.<actions> item normally in the e2 context menu, does interrogate available .desktop files. However I've just realised that the approach taken is probably wrong - uses the "Actions" key instead of "MimeType" and "Exec".

Memo to self - I must remember not to try to remember, but actually check ...

The final comment above is wrong, the code is right, but limited. Applies only to executable items.

The same sort of approach applied to other types of file would require opening and parsing literally hundreds of .desktop files, to find which one(s) of them can handle the selected item - NOT the way to go.

However if xdg-mime command is available, that can supply the .desktop file (without path) of the 'preferred' handler. After finding and parsing that file, it's easy to add that item to the menu. This is working now, in svn code.

For a more comprehensive list of handlers - well, back to the freedesktop documentation issue.

Regards
Tom

[Liviu Andronic]

Post by t***@onepost.net
However if xdg-mime command is available, that can supply the .desktop file (without path) of the 'preferred' handler. After finding and parsing that file, it's easy to add that item to the menu. This is working now, in svn code.

It seems to be working fine in r2522. Thanks!

But again, as suggested earlier, could we get a file.<mime-actions>,
and perhaps a bit more. For some file types I would like that the
xdg-mime suggestion be the default, that is before all the internal
filetype scheme items. While for others I would like to keep emel
defaults (or customizations). Would it be difficult to implement this?

Post by t***@onepost.net
For a more comprehensive list of handlers - well, back to the freedesktop documentation issue.

That's a bummer indeed.

Regards
Liviu

[t***@onepost.net]

On Sat, 26 May 2012 15:57:18 +0200

Post by Liviu Andronic

Post by t***@onepost.net
However if xdg-mime command is available, that can supply the .desktop file (without path) of the 'preferred' handler. After finding and parsing that file, it's easy to add that item to the menu. This is working now, in svn code.

It seems to be working fine in r2522. Thanks!
But again, as suggested earlier, could we get a file.<mime-actions>,
and perhaps a bit more. For some file types I would like that the
xdg-mime suggestion be the default, that is before all the internal
filetype scheme items. While for others I would like to keep emel
defaults (or customizations). Would it be difficult to implement this?

There could be another action, but from FDO ML chatter, it's probably better thought of as file.<applications> or something, as it would be based on a collation of data from .desktop files, only partly and loosely related to mimetype. Somebody is working on a revised library, and command, to produce this sort of data. Who knows when it will be complete and released and widely available.

If there were a new action, then you choose - show it or not in the context menu, and if so, before or after file.<actions> or somewhere else, not type-specific positioning.

Regards
Tom

[t***@onepost.net]

On Sun, 27 May 2012 12:49:21 +1000

Post by t***@onepost.net
There could be another action, but from FDO ML chatter, it's probably better thought of as file.<applications> or something, as it would be based on a collation of data from .desktop files, only partly and loosely related to mimetype. Somebody is working on a revised library, and command, to produce this sort of data. Who knows when it will be complete and released and widely available.
If there were a new action, then you choose - show it or not in the context menu, and if so, before or after file.<actions> or somewhere else, not type-specific positioning.

Svn code now includes an action named file.<handlers>, intended for the filelist context menu. The action merely includes in the menu items which were formerly included as part of file.<actions>. Specifically:
* for a non-executable item - the default 'handler' reported by xdg-mime, and
* for an executable item - any commands/actions listed in the corresponding .desktop file (if any).

If or when there's a reasonably practical mechanism for detecting non-executable-handlers other than the default, that can be dropped in easily.

Regards
Tom