Differences

This shows you the differences between two versions of the page.

--- doc:appunti:linux:tux:mimetype [2020/09/13 19:25] – [MIME Type application/x-image-playlist] niccolo
+++ doc:appunti:linux:tux:mimetype [2020/09/23 21:43] (current) – [MIME Type application/x-image-playlist] niccolo
@@ Line 56: / Line 56: @@
 <code xml>
+<!-- WARNING! This file is not optimal, see below for the final version. -->
 <?xml version="1.0" encoding="UTF-8"?>
 <mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
@@ Line 85: / Line 86: @@
 We can solve the problem by choosing a different filename extension and add another **%%<glob pattern="..."/>%%** line into the XML definition, but here we want to show how to override the default preference order. So we add the **%%weight="60"%%** attribute to the **glob** tag, knowing that the default weight is 50 (the value must be between 0 and 100).
-Executing the **update-mime-database** tool, the **globs** and **globs2** files are updated. They contain the mime type and the associated extension; if **globs2** exists, it is preferred because it contains the //weight// data, otherwise **globs** is used (where only the listing order matters). **WARNING**! Not all the MIME query tools behave in the same way: **gio** and **mimetype** are known to return different results for the same file; one reason is that the files in **/usr/local/share/mime/** and **/usr/share/mime/** are not treated in the same way by the two programs.
+Executing the **update-mime-database** tool, the **globs** and **globs2** files are updated. They contain the mime type and the associated extension; if **globs2** exists, it is preferred because it contains the //weight// data, otherwise **globs** is used (where only the listing order matters).
+**WARNING**! Not all the MIME query tools behave in the same way: **gio** (from the **libglib2.0-bin** package) and **mimetype** (from the **libfile-mimeinfo-perl** package) are known to return different results for the same file; one reason is that the files in **/usr/local/share/mime/** and **/usr/share/mime/** are not treated in the same way by the two programs.
 Here we face **the second problem**, despite the .m3u extension is associated to our custom MIME Type with more //weigth// than the default audio/x-mpegurl type, **xdg-mime** returns the same result as above.
@@ Line 140: / Line 143: @@
 application/x-image-playlist
 </code>
+==== Configuration system-wide or user-wide ====
+The MIME related tools search for the MIME database in several directories. On a Debian system there is the directory where offical packages install their definitions, the directory where the system administrator can install local configuration valid for all the users, and the user's personal directory:
+  * **/usr/share/mime/**
+  * **/usr/local/share/mime/**
+  * **$HOME/.local/share/mime/**
 ===== Application associated to a MIME Type =====
-FIXME To be continued...
+To view if there is an application associated with our custom MIME Type, we can run the following command. No result is returned, as we can expect:
+<code>
+xdg-mime query default application/x-image-playlist
+</code>
+We check also the behaviour of the **Firefox** browser, we prepare an HTML file containing this (notice the **anchor** tag uses the **type** attribute to declare the proper MIME type):
+<code xml>
+<a href="playlist.m3u" type="application/x-image-playlist">Image Slideshow</a>
+</code>
+Once clicked the link, Firefox displays the //Open with...// dialog box suggesting to use **VLC** to open the **MPEG Audio URL**.  If you click over the //Other...// option, Firefox says **No applications found for "M3U Images Playlist" files**. The MIME Type is recognized, but the application to handle it is unknown.
+Now we prepare a file and save it as **/usr/local/share/applications/photo-reframe.desktop**:
+<file>
+[Desktop Entry]
+# The format of this file is specified at
+# http://standards.freedesktop.org/desktop-entry-spec/1.0/
+# The entries are in the order they are listed in version 1.0
+Type=Application
+# This is the version of the spec for this file, not the application version.
+Version=1.0
+Name=Photo-Reframe
+GenericName=Image Viewer
+Comment=Slideshow with on-the-fly image cropping
+Icon=image
+TryExec=photo-reframe
+Exec=photo-reframe --fullscreen --play %f
+Terminal=false
+MimeType=application/x-image-playlist;
+# Category entry according to:
+# http://standards.freedesktop.org/menu-spec/1.0/
+Categories=Graphics;2DGraphics;RasterGraphics;Qt;
+</file>
+then we run the **update-desktop-database** over that directory (it will update the **mimeinfo.cache** file in the same directory):
+<code>
+update-desktop-database /usr/local/share/applications/
+</code>
+Something good has happened; the system knows how to handle that MIME type:
+<code>
+xdg-mime query default application/x-image-playlist
+photo-reframe.desktop
+</code>
+After this step, Firefox suggests to use **Photo-Reframe (default)** to handle the link, you can check the box **Do this automatically for files like this from now on** and the associated application will be launched automatically whenever you will click over a link like this. Only after this association, you can open the Firefox **Preferences** => **Applications** and browse for the //M3U Images Playlist// and assign the preferred action.
+**NOTICE**: You may need to use **Shift-Click** to force the reloading of the link, otherwise Firefox may get the object from the cache, where the MIME type is cached too.
+===== Useless recipes =====
+There are many recipes to add a new MIME Type and an associated applications, many of them suggest to edit some system files. In our experience it is **absolutely useless to modify** the following files:
+  * /etc/mailcap
+  * /etc/mime.types
+  * $HOME/.mozilla/firefox/<profile>.default/mimeTypes.rdf
+  * $HOME/.mozilla/firefox/<profile>.default/handlers.json
+===== Opening local files from an HTTP page =====
+For security reasons a web browser does not allow to open a **%%file://%%** link from a page loaded via a network protocolo, like **%%http://%%**. This is obvious because you don't want to allow a remote sito to fiddle with objects stored on your local disk. But for our application we need this indeed: a page loaded from **%%http://localhost/gallery.php%%** must execute a local program passing a local file path to it, something like **/home/data/directory/playlist.m3u**.
+The link on the HTML page will look something like this:
+<code html>
+<a href="file:///home/data/directory/playlist.m3u">
+    <img src="directory/folder.jpg">
+</a>
+</code>
+To bypass the Firefox restriction, you have to create an **user.js** file in your profile directory, something like **$HOME/.mozilla/firefox/3e4ghyw2.default/user.js** (tested with Firefox 68.4):
+<code javascript>
+user_pref("capability.policy.policynames", "localfilelinks");
+user_pref("capability.policy.localfilelinks.sites", "http://localhost");
+user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
+</code>
 ===== Web References =====
@@ Line 151: / Line 244: @@
   * **[[https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types|MIME types (IANA media types)]]**
   * **[[https://www.december.com/html/spec/mime.html|MIME Types]]**
+  * **[[http://kb.mozillazine.org/Links_to_local_pages_do_not_work|Links to local pages do not work]]**