mimeo: open files by mimetype or file name

rtfupi · 2016-04-18 15:19:36

Xyne wrote:

rtfupi wrote:
Thank you for the clarification. I'll try to ask about this in freedesktop@lists.freedesktop.org
If it turns out that I have misunderstood the specification or if they decide to change it, let me know and I will update mimeo.

Ok

likytau · 2016-07-10 05:55:02

I'm currently stuck trying to make mimeo open tmsu:// uris with my custom scheme handler. This is odd because mimeo used to do this fine -- and "gnome-open tmsu://q/foo" still works fine, and directly invoking "~/bin/tmsu-schemahandler.sh tmsu://q/foo" works fine.

Anyone got an idea what the cause might be here?

Details are as follows:

* "mimeo -m tmsu://q/foo" correctly returns "x-scheme-handler/tmsu"
* "mimeo -m | grep tmsu" correctly(?) returns "x-scheme-handler/tmsu"
* "mimeo -c tmsu://q/foo" or "mimeo tmsu://q/foo" return errors "failed to determine command(s) for tmsu://q/foo"
* Creating a new minimal desktop file using mimeo appears to work: "mimeo --create testify.desktop 'tmsu-schemahandler' '/home/kau/bin/tmsu-schemahandler.sh %u' x-scheme-handler/tmsu ''. The result (~/.local/share/applications/testify.desktop) is as follows:

[Desktop Entry]
Type=Application
Name=tmsu-schemahandler
Exec=/home/kau/bin/tmsu-schemahandler.sh %u
MimeType=x-scheme-handler/tmsu;
Terminal=false
NoDisplay=true
Comment=Created by Mimeo

* Adding it to ~/.config/mimeapps.list via `mimeo --debug --prefer x-scheme-handler/tmsu testify.desktop` works (a record is added)
* However, "mimeo -c tmsu://q/foo" or "mimeo tmsu://q/foo" still returns errors "failed to determine command(s) for tmsu://q/foo"...
* and "mimeo -d tmsu://q/foo" returns "None"

Xyne · 2016-07-10 06:07:47

Have you tried using the "--deprecated" option? ~/.local/share/applications is no longer supported by the standard but the current standard provides no replacement location for custom desktop files. Several common openers still use the deprecated directories which is probably why they still work.

You could also use a custom association file instead of a user-created desktop file. See "mimeo --assoc-help" for details.

likytau · 2016-07-10 06:16:39

Thanks for the quick response!

--deprecated works... (seems pretty broken that the current standard doesn't have a location for custom desktop files!)

Association file also works (I was avoiding that because I thought there was a 'more correct'/universal way to fix it)

Xyne · 2016-07-10 06:29:56

likytau wrote:

seems pretty broken that the current standard doesn't have a location for custom desktop files!

I agree. I don't get the thought process there either. It seems like one of those cases where someone got lost following some warped ideal and left practicality behind.

Alad · 2016-10-30 12:21:31

Maybe I'm missing something but the regex option as documented in mimeo --mimeman-help just writes the pattern literally to XDG_CONFIG_HOME/mimeapps.list:

[archie@thinkpad .config]$ expac -S '%v' mimeo
2016.2-1
[archie@thinkpad .config]$ mimeo --prefer 'regex:^image/(png|jpe?g)$' gqview.desktop
[archie@thinkpad .config]$ grep regex mimeapps.list 
regex:^image/(png|jpe?g)$=gqview.desktop;

Xyne · 2016-11-02 17:05:07

You're not missing anything. I was missing an "n"
Fixed in mimeo-2016.11-1. Thanks for reporting the error.

Alad · 2016-11-02 17:45:36

Works fine with the new version, cheers.

Alad · 2016-11-05 04:16:45

I wrote a man page based on mimeo --help:

https://paste.xinu.at/qapF/

I wasn't sure on what to do with the last paragraph, so I put one part in DESCRIPTION and the other at the top of Configuration Options. If you're interested I can write man pages for --assoc-help, --mimeman-help and --filepath-help as well.

Xyne · 2016-11-05 22:49:25

I appreciate the contribution but I prefer to leave the documentation embedded in the module for now. The main help message is automatically generated by the argparse module and therefore always up-to-date. A separate man page would not provide new information yet require additional (although admittedly little) effort to synchronize changes. It may make sense to move the embedded static help messages to proper man pages but currently the main module can be used as a stand-alone utility with full documentation without any system-wide installation.

Looking at the message functions, I see that even the "static" messages use some interpolation to guarantee that some displayed values are up-to-date.

edit
Accidentally sent before I had finished. I am open to discussing the idea but I don't see any immediate benefit from providing separate man pages.

Incidentally, the man pages that I provide for other packages are written in markdown and converted to man pages with pandoc.

Last edited by Xyne (2016-11-05 22:51:04)

farsil · 2016-11-27 00:38:46

(sorry, rather long post)

Hello there, I am currently testing your utility (and xdg-utils-mimeo) because I was fed up I couldn't be able to stow properly my mimeapps.list with the suggested perl-file-mimeinfo package (I don't use a DE).

It is much smarter than mimeopen in handling the various locations, and I thank you for the effort you put into developing this tool.

However, I'm rather perplexed about how defaults are selected and path resolution. I'll report my (very specific) case in detail to better explain my point.

I use feh as my default image viewer, as it's blazing fast. You can customize how it works by passing command line arguments to the executable. I wanted to make it work with mimeo/xdg-open, so I created a file feh.desktop in $XDG_DATA_HOME/applications with the customized command. I also modified my $XDG_CONFIG_HOME/mimeapps.list accordingly:

...
image/png=feh.desktop;
...

When I try to open an image file with mimeo this is what happens:

silver@blacklotus:~/.local/share/applications$ mimeo --debug -c /tmp/downloads/wallpaper.png
DEBUG: loading arguments from /home/silver/.local/etc/mimeo/default_arguments.txt
DEBUG: opening /home/silver/.local/etc/mimeo/associations.txt
DEBUG: /home/silver/.local/etc/mimeo/associations.txt does not exist
DEBUG: loading /home/silver/.local/etc/mimeapps.list
DEBUG: loading /usr/share/applications/mimeapps.list
DEBUG: parsing /usr/share/applications/feh.desktop
feh /tmp/downloads/wallpaper.png

mimeo correctly reads my user configuration file but still decides to go with the system-wide feh.desktop. So I tried to force mimeo to use my desktop file with --user:

silver@blacklotus:~/.local/share/applications$ mimeo --debug -c --user /tmp/downloads/wallpaper.png
DEBUG: loading arguments from /home/silver/.local/etc/mimeo/default_arguments.txt
DEBUG: opening /home/silver/.local/etc/mimeo/associations.txt
DEBUG: /home/silver/.local/etc/mimeo/associations.txt does not exist
DEBUG: loading /home/silver/.local/etc/mimeapps.list
DEBUG: failed to determine at least one desktop for image/png
WARNING: failed to determine command precursor for /tmp/downloads/wallpaper.png
WARNING: failed to determine command(s) for /tmp/downloads/wallpaper.png

And it fails to find the corresponding entry! At this point I thought mimeo didn't use my feh.desktop because it couldn't find it, so I tried to embed the path information for the customized feh.desktop file in my $XDG_CONFIG_HOME/mimeapps.list:

...
image/png=/home/silver/.local/share/applications/feh.desktop;
...

At this point I try mimeo again:

silver@blacklotus:~/.local/share/applications$ mimeo --debug -c --user /tmp/downloads/wallpaper.png
DEBUG: loading arguments from /home/silver/.local/etc/mimeo/default_arguments.txt
DEBUG: opening /home/silver/.local/etc/mimeo/associations.txt
DEBUG: /home/silver/.local/etc/mimeo/associations.txt does not exist
DEBUG: loading /home/silver/.local/etc/mimeapps.list
DEBUG: parsing /home/silver/.local/share/applications/feh.desktop
feh --scale-down /tmp/downloads/wallpaper.png

Great! now it works. But here's what happens when I go system-wide:

silver@blacklotus:~/.local/share/applications$ mimeo --debug -c /tmp/downloads/wallpaper.png
DEBUG: loading arguments from /home/silver/.local/etc/mimeo/default_arguments.txt
DEBUG: opening /home/silver/.local/etc/mimeo/associations.txt
DEBUG: /home/silver/.local/etc/mimeo/associations.txt does not exist
DEBUG: loading /home/silver/.local/etc/mimeapps.list
DEBUG: loading /usr/share/applications/mimeapps.list
DEBUG: parsing /usr/share/applications/feh.desktop
feh /tmp/downloads/wallpaper.png

It falls back to the default one again!

Now, according to my knowledge of the XDG standard aren't user overrides supposed to have priority compared to system defaults? It seems that mimeo does the opposite. As far as I've observed, it does not appear to check for existence of desktop files in $XDG_DATA_HOME/applications if a corresponding file is found in /usr/share/applications. Likewise, it gives more priority to /usr/share/applications/mimeapps.list compared to $XDG_CONFIG_HOME/mimeapps.list.

Shouldn't mimeo do the opposite? Am I missing something? Did I get the standard wrong? I know this is possibly a corner case but I wanted to report it in case it could be of assistance.

Last edited by farsil (2016-11-27 00:40:18)

Xyne · 2016-12-03 18:43:05

Mimeo parses the user files first and uses those associations before the system associations. I have a custom feh desktop file in the same location as you and mimeo correctly selects it for image files. That said, I don't know what's going on here. At first I thought it might be a MIME-type detection error but using the full path.

First, some sanity checks:

What version of mimeo are you using?

What is the output of the following?:

mimeo -m /tmp/downloads/wallpaper.png
mimeo --debug --finddesk feh.desktop
echo "$XDG_DATA_HOME"

What happens if you change the name of your custom file to "fehtest.desktop" and update the association?
What is the output of
```
mimeo --debug --finddesk fehtest.desktop
```
after creating that file?

I have updated mimeo (version 2016.12) to add the scanned mimeapps directories to the debugging messages. Please update to the latest version and post the output from the commands above with it. The new version should be up in

farsil · 2016-12-04 12:34:33

Before I start, I will maybe anticipate a question by saying that I set my $XDG_CONFIG_HOME to $HOME/.local/etc because I like to keep all my user files in .local:

$ echo $XDG_CONFIG_HOME
/home/silver/.local/etc

Xyne wrote:

What version of mimeo are you using?

$ pacman -Q mimeo
mimeo 2016.11-1

Xyne wrote:

What is the output of the following?

$ mimeo -m ~/wallpaper.png
/home/silver/wallpaper.png
  image/png

$ mimeo --debug --finddesk feh.desktop
DEBUG: loading arguments from /home/silver/.local/etc/mimeo/default_arguments.txt
DEBUG: opening /home/silver/.local/etc/mimeo/associations.txt
DEBUG: /home/silver/.local/etc/mimeo/associations.txt does not exist
/usr/share/applications/feh.desktop

$ echo "$XDG_DATA_HOME"
/home/silver/.local/share

Xyne wrote:

What happens if you change the name of your custom file to "fehtest.desktop" and update the association?
What is the output of
mimeo --debug --finddesk fehtest.desktop
after creating that file?

This is without full path specification.

$ ls $XDG_DATA_HOME/applications | grep feh
fehtest.desktop

$ < $XDG_CONFIG_HOME/mimeapps.list grep png
image/png=fehtest.desktop;
image/x-png=fehtest.desktop;

$ mimeo --debug --finddesk fehtest.desktop
DEBUG: loading arguments from /home/silver/.local/etc/mimeo/default_arguments.txt
DEBUG: opening /home/silver/.local/etc/mimeo/associations.txt
DEBUG: /home/silver/.local/etc/mimeo/associations.txt does not exist

$ mimeo --debug ~/wallpaper.png
DEBUG: loading arguments from /home/silver/.local/etc/mimeo/default_arguments.txt
DEBUG: opening /home/silver/.local/etc/mimeo/associations.txt
DEBUG: /home/silver/.local/etc/mimeo/associations.txt does not exist
DEBUG: loading /home/silver/.local/etc/mimeapps.list
DEBUG: loading /usr/share/applications/mimeapps.list
DEBUG: loading /usr/share/applications/mimeinfo.cache
DEBUG: parsing /usr/share/applications/feh.desktop
DEBUG: feh /home/silver/wallpaper.png

Xyne wrote:

Please update to the latest version and post the output from the commands above with it.

This is with feh.desktop renamed to fehtest.desktop:

$ mimeo --debug --finddesk fehtest.desktop
DEBUG: loading arguments from /home/silver/.local/etc/mimeo/default_arguments.txt
DEBUG: opening /home/silver/.local/etc/mimeo/associations.txt
DEBUG: /home/silver/.local/etc/mimeo/associations.txt does not exist
DEBUG: mimeapps_directories:
  /home/silver/.local/etc
DEBUG: mimeapps_directories:
  /etc/xdg
DEBUG: mimeapps_directories:
  /usr/local/share/applications
  /usr/share/applications

$ mimeo --debug ~/wallpaper.png
DEBUG: loading arguments from /home/silver/.local/etc/mimeo/default_arguments.txt
DEBUG: opening /home/silver/.local/etc/mimeo/associations.txt
DEBUG: /home/silver/.local/etc/mimeo/associations.txt does not exist
DEBUG: mimeapps_directories:
  /home/silver/.local/etc
DEBUG: loading /home/silver/.local/etc/mimeapps.list
DEBUG: mimeapps_directories:
  /etc/xdg
DEBUG: mimeapps_directories:
  /usr/local/share/applications
  /usr/share/applications
DEBUG: loading /usr/share/applications/mimeapps.list
DEBUG: mimeapps_directories:
  /home/silver/.local/etc
DEBUG: mimeapps_directories:
  /etc/xdg
DEBUG: mimeapps_directories:
  /usr/local/share/applications
  /usr/share/applications
DEBUG: mimeapps_directories:
  /home/silver/.local/etc
DEBUG: mimeapps_directories:
  /etc/xdg
DEBUG: mimeapps_directories:
  /usr/local/share/applications
  /usr/share/applications
DEBUG: loading /usr/share/applications/mimeinfo.cache
DEBUG: parsing /usr/share/applications/feh.desktop
DEBUG: feh /home/silver/wallpaper.png

Extra

At this point I tried to specify the full path in mimeapps.list:

$ < $XDG_CONFIG_HOME/mimeapps.list grep png
image/png=/home/silver/.local/share/applications/fehtest.desktop;
image/x-png=/home/silver/.local/share/applications/fehtest.desktop;

Mimeo still cannot find the desktop file with --finddesk:

$ mimeo --debug --finddesk fehtest.desktop
DEBUG: loading arguments from /home/silver/.local/etc/mimeo/default_arguments.txt
DEBUG: opening /home/silver/.local/etc/mimeo/associations.txt
DEBUG: /home/silver/.local/etc/mimeo/associations.txt does not exist
DEBUG: mimeapps_directories:
  /home/silver/.local/etc
DEBUG: mimeapps_directories:
  /etc/xdg
DEBUG: mimeapps_directories:
  /usr/local/share/applications
  /usr/share/applications

But it correctly uses fehtest when opening!

$ mimeo --debug ~/wallpaper.png
DEBUG: loading arguments from /home/silver/.local/etc/mimeo/default_arguments.txt
DEBUG: opening /home/silver/.local/etc/mimeo/associations.txt
DEBUG: /home/silver/.local/etc/mimeo/associations.txt does not exist
DEBUG: mimeapps_directories:
  /home/silver/.local/etc
DEBUG: loading /home/silver/.local/etc/mimeapps.list
DEBUG: mimeapps_directories:
  /etc/xdg
DEBUG: mimeapps_directories:
  /usr/local/share/applications
  /usr/share/applications
DEBUG: loading /usr/share/applications/mimeapps.list
DEBUG: mimeapps_directories:
  /home/silver/.local/etc
DEBUG: parsing /home/silver/.local/share/applications/fehtest.desktop
DEBUG: feh --scale-down /home/silver/wallpaper.png

Do you think the problem lies in the path resolution?

Last edited by farsil (2016-12-04 12:38:00)

Xyne · 2016-12-04 14:10:45

I was too tired to catch it when looking at this yesterday. The problem is due to the deprecation of "$XDG_DATA_HOME/applications" in the XDG standard. Custom desktop files in that directory used to be supported but no longer are. Mimeo has an option to re-enable the deprecated directories (--deprecated). I have that option in my default arguments file in Mimeo's configuration directory to use some custom desktop files such as feh.

Incidentally, the current standard does not support any custom user desktop files: desktop files are only allowed to be located in system directories now. I do not understand why they deprecated something so useful. That is also why --finddesk and related options fail to discover the desktop file, even when the full path is given in the mimeapps file. The standard specifies which directories to scan for desktop files. The mimeapps files should only specify the names of desktop files, not the full path. Mimeo only supports the full path due to the naïve assumption that the mimeapps file only specifies names, which it joins to the directory path using the standard library's os.path.join function. If the "name" is a full path, that function will return it.

Although being able to specify the full path may be useful, Mimeo should probably ignore full paths to conform to the standard.

tl;dr: Mimeo follows the standard but the standard deprecated custom user desktop files: use "--deprecated" to restore that functionality

farsil · 2016-12-04 15:25:14

Are you sure it is deprecated? I see that the official specification still references $XDG_DATA_HOME/applications as a place to look for desktop files. Relevant part:

This means that additions and removals applied from the mimeapps.list file in $XDG_CONFIG_HOME, $XDG_CONFIG_DIRS and $XDG_DATA_HOME will override all existing desktop files, but that an addition or removal of an association using /usr/share/applications/mimeapps.list, for example, would be ignored if the desktop file of the named application was present in $XDG_DATA_HOME/applications.

Edit: I am talking specifically about the location of desktop files. I am aware that mimeapps.list in $XDG_DATA_HOME/applications is already deprecated.

Last edited by farsil (2016-12-04 17:26:02)

eschwartz · 2016-12-04 16:35:00

Xyne, that directory is listed in the table at the top as "for compatibility, deprecated", and they clearly reference using it anyway later on; it seems clear that the spec discourages their use (because you should only use $XDG_CONFIG_HOME, but due to an embarrassingly idiotic oversight in writing the spec, there is no recommended way to add actual *.desktop files)... however, you can still use them with the caveat that deprecated anything is not guaranteed to continue to be available. That's what "deprecation" means, as opposed to "removed features".

So the correct approach is clearly to remove the --deprecated flag from mimeo, make that the default instead, and possibly spam the user with deprecation warnings whenever such *.desktop/*mimeapps.list files are found.

likytau · 2016-12-05 08:26:41

Eschwartz : That's a good point. Put in those terms, the 'normal-ish' thing to do would probably be to invert it into a '--strict' switch, since having at least one of (switch to disable deprecated features, switch to warn about deprecated features) is fairly common WRT deprecated interfaces.

Xyne · 2016-12-05 19:49:12

From a developer's standpoint, switching away from deprecated code and behavior is good practice. The user can easily add the argument to an alias or the default arguments file to restore the old behavior. This also makes it clear that the behavior may disappear unexpectedly in the future.* The current approach seems more reasonable to me than adding an option for strict mode. I am aware that some common software likely still uses the old behavior by default but that is not a convincing argument, even if I understand how that leads to certain expectations for Mimeo.

* Hypothetically at least. I plan to leave the option until the standard provides a new day to support user desktop files, or the XDG guys break down my door and waterboard me until I agree to remove it.

farsil · 2016-12-06 11:58:49

I am still not convinced it is deprecated. It is definitely not clear in the specification.

For one, it makes sense that mimeapps.list stays in $XDG_CONFIG_HOME, as it's the natural place for user overrides. Deprecating $XDG_DATA_HOME/applications/mimeapps.list makes sense because we don't need two places for user overrides, and, for consistency's sake, since system overrides are put in $XDG_CONFIG_DIRS, user overrides should be in $XDG_CONFIG_HOME.

However, it also makes sense that $XDG_DATA_HOME/applications would contain all the user desktop files, again, for consistency's sake. System desktop files reside in $XDG_DATA_DIRS/applications, so it is only natural that user desktop files would reside in $XDG_DATA_HOME/applications. They really have no place in $XDG_CONFIG_HOME, they're not configuration files.

I strongly believe the deprecation notice is about the location of the mimeapps.list file only. There is no specific mention that the deprecation warning refers to desktop files as well.

Regardless of that, for now I'll just use the --deprecated flag.

Last edited by farsil (2016-12-06 12:01:45)

eschwartz · 2016-12-07 05:48:30

farsil wrote:

I am still not convinced it is deprecated. It is definitely not clear in the specification.
For one, it makes sense that mimeapps.list stays in $XDG_CONFIG_HOME, as it's the natural place for user overrides. Deprecating $XDG_DATA_HOME/applications/mimeapps.list makes sense because we don't need two places for user overrides, and, for consistency's sake, since system overrides are put in $XDG_CONFIG_DIRS, user overrides should be in $XDG_CONFIG_HOME.
However, it also makes sense that $XDG_DATA_HOME/applications would contain all the user desktop files, again, for consistency's sake. System desktop files reside in $XDG_DATA_DIRS/applications, so it is only natural that user desktop files would reside in $XDG_DATA_HOME/applications. They really have no place in $XDG_CONFIG_HOME, they're not configuration files.
I strongly believe the deprecation notice is about the location of the mimeapps.list file only. There is no specific mention that the deprecation warning refers to desktop files as well.
Regardless of that, for now I'll just use the --deprecated flag.

How very logical of you.

Really. I quite agree with everything you said. The problem is that whoever wrote the spec specifically defined *.desktop file locations as "in the same directory as mimeapps.list", and upon deprecating "$XDG_DATA_HOME/applications/mimeapps.list" they failed to notice that, technically, they deprecated those *.desktop files as well.

Granted, that apparently every DE out there solved the issue by saying "silly freedesktop, we will continue to support what makes sense". But Xyne used his "I am the developer" powers to veto emulating that.
At least we can warn all mimeo users that mimeo should always be used with --deprecated.

...

You can say "it's not clear that user *.desktop files are deprecated", but I say "the spec doesn't define what is different from before, it defines a spec."

And the spec is missing any reference to $XDG_DATA_HOME except in reference to the "deprecated" mimeapps.list
Which, granted, is a huge oversight.

Last edited by eschwartz (2016-12-07 05:50:35)

Xyne · 2016-12-07 14:19:36

After digging around in the standard I found this section that explicitly supports user-specific desktop files in the $XDG_DATA_HOME/applications directory. I have modified Mimeo to work as expected without the --deprecated flag. That flag can still be used to parse mimeapps.list files in the user applications directory.

I will upload the new version in a few hours.

farsil · 2016-12-07 14:35:26

Xyne wrote:

After digging around in the standard I found this section that explicitly supports user-specific desktop files in the $XDG_DATA_HOME/applications directory. I have modified Mimeo to work as expected without the --deprecated flag. That flag can still be used to parse mimeapps.list files in the user applications directory.
I will upload the new version in a few hours.

As an additional confirmation, I decided to send the authors of the specification an email asking about the deprecation of the $XDG_DATA_HOME/application folder. I got this reply from David Faure:

David Faure wrote:

> Dear authors,
>
> I have a simple question about the specification mentioned in the subject.
> In the specification, you mention the deprecation of the file
> $XDG_DATA_HOME/applications/mimeapps.list.
Yes.
> Does that mean looking for desktop files put in $XDG_DATA_HOME/applications
> is deprecated as well?
No, desktop files still belong to $XDG_DATA_HOME/applications,
it's just that the mimeapps.list file belongs to $XDG_CONFIG_HOME.

Last edited by farsil (2016-12-07 14:35:51)

eschwartz · 2016-12-07 16:22:13

Oh. Well, this could have been solved from the start if they had a spec for desktop files. Rather than leaving us to choose between oblique mentions in the mimeapps.list spec and the xdg-menu (what is this thing for anyway???) spec.

If it's not all one big spec (we have at least two) then why not have a spec for each?

Xyne · 2016-12-07 20:33:02

Eschwartz wrote:

... and the xdg-menu (what is this thing for anyway???)

If you figure it out, let me know. I only skimmed it. I started to look at the format for files in "sysconfdir/menus/applications-merged/" and "datadir/desktop-directories/" wondering if I need to implement any of that in Mimeo (or ObFileBrowser's desktop menu) but then realized it was a time trap that I can't afford to fall into right now

Anyway, mimeo-2016.12.7 is up with the correct default behavior. Let me know if any bugs sneaked in.

HyperHamster · 2016-12-14 06:40:26

Is there a reason why the --clear option will only clear an association if it's not the only/last association for that mimetype in the mimeapps.list file? The description of the --clear option in the --help implies that it should do this and does not specify this as an exception; although I believe this to be how it should behave as I see no reason why it shouldn't be able to clear the last (whole) association for a mimetype.

Arch Linux

#151 2016-04-18 15:19:36

Re: mimeo: open files by mimetype or file name

#152 2016-07-10 05:55:02

Re: mimeo: open files by mimetype or file name

#153 2016-07-10 06:07:47

Re: mimeo: open files by mimetype or file name

#154 2016-07-10 06:16:39

Re: mimeo: open files by mimetype or file name

#155 2016-07-10 06:29:56

Re: mimeo: open files by mimetype or file name

#156 2016-10-30 12:21:31

Re: mimeo: open files by mimetype or file name

#157 2016-11-02 17:05:07

Re: mimeo: open files by mimetype or file name

#158 2016-11-02 17:45:36

Re: mimeo: open files by mimetype or file name

#159 2016-11-05 04:16:45

Re: mimeo: open files by mimetype or file name

#160 2016-11-05 22:49:25

Re: mimeo: open files by mimetype or file name

#161 2016-11-27 00:38:46

Re: mimeo: open files by mimetype or file name

#162 2016-12-03 18:43:05

Re: mimeo: open files by mimetype or file name

#163 2016-12-04 12:34:33

Re: mimeo: open files by mimetype or file name

Extra

#164 2016-12-04 14:10:45

Re: mimeo: open files by mimetype or file name

#165 2016-12-04 15:25:14

Re: mimeo: open files by mimetype or file name

#166 2016-12-04 16:35:00

Re: mimeo: open files by mimetype or file name

#167 2016-12-05 08:26:41

Re: mimeo: open files by mimetype or file name

#168 2016-12-05 19:49:12

Re: mimeo: open files by mimetype or file name

#169 2016-12-06 11:58:49

Re: mimeo: open files by mimetype or file name

#170 2016-12-07 05:48:30

Re: mimeo: open files by mimetype or file name

#171 2016-12-07 14:19:36

Re: mimeo: open files by mimetype or file name

#172 2016-12-07 14:35:26

Re: mimeo: open files by mimetype or file name

#173 2016-12-07 16:22:13

Re: mimeo: open files by mimetype or file name

#174 2016-12-07 20:33:02

Re: mimeo: open files by mimetype or file name

#175 2016-12-14 06:40:26

Re: mimeo: open files by mimetype or file name

Board footer