KDE MIME Types and 'Applications'

How it all works.

The KFM browser checks for an association for ANY file and a program to handle it, in TWO ways.

• The easiest to follow is by dot extension. Thus anything.txt is associated with a text editor application (for instance). The preferred text editor is alterable.

• On the other hand, dot extension attributes never took off in the Unix world. File naming was and always has been a free for all. Thus, KFM is a lot smarter, in addition to the above dot extension methods it additionally has what is called a 'magic file' in /opt/kde/share/mimelnk. This file is used to sniff at the first bytes of any file to determine what it might be.

Like almost everything Linux the magic file is an easily maintainable, human readable, text file. It's syntax is very straightforward.

<offset> <search type> <value> <mime/type>

le.

If the file being inspected matches the requirement above (eg a string called "jx_browser") then this file is an "thingo/whatsit" mime type.

Using the steps outlined previously, you can as easily associate all (dot)specific_extension files to "thingo/whatsit"

THINGO/WHATSIT

From KFM's point of view this entire string is one word. KFM does not associate application/something as being any more special than myspecialname/myspecialthingo. It is one word for KFM.

However, for the human, we tend to categorise so that

editors/anthything
html/anything
applications/anything

Make sense to us. We would tend to put all our editors in editors/<list of editor programs>

This becomes important later on when I describe the mime type file structure, as there is NO relationship between thingo/whatsit and a folder called thingo (should we choose to call it that), other than specific hard coded links we tell kfm to make.

KFM MIME LOCATIONS

KFM distinguishes two separate mime areas.

You must be very careful in your thinking here. The root superuser is just another user for KFM. Being root, does not entitle you to use of user-specific mimetypes. You have your own $HOME/(dot)kde/mimelnk directory for root just like any other user. Again, providing root only mime links is (obviously?) not the same as providing global mimelinks. However, the only way you can provide global mimelinks is by being root. Why? Because root is the only time KFM allows you to edit the global directory.

GLOBAL MIMES

By now, having read the previous step pages, you should be reasonably familiar with the differences between mimes for everyone (global) and mimes just for you. When you edit->mimetypes, you are normally shown, in addition to any personal ones of yours (if any), the entire global suite as well. The Global mimes are READ ONLY, they are their simply for your information. Unless you're root, you can't touch them. My take on this is that they shouldn't be displayed at all. However, being a technical document, I need to point out the curious and interesting manner in which KFM displays these items for you.

Everyone (should be) familiar with symbolic links. In an ordinary world, KFM could have provided symbolic links from the $HOME/(dot)kde/share/mimelnk directory to the /opt/kde/share/mimelink directory. If you ls -la your personal mimelink directory you wont find anything there other than your personal mimes (if any), and yet, the KFM browser displays them!

KFM treats $HOME/(dot)kde/share/any_folder as extensions to it's /opt/kde/share/any_folder. It is purely an internal KFM mechanism.

The ROOT special case:

The only time this mechanism does NOT apply (inherent inclusion of /opt/kde/share) is the root superuser. All she will see is the literal personal mimetypes. In my opinion this should be the defacto case for everything, but that is irrelevant because this document desctibes how it is, not how it should be..

MIMES -> APPLICATIONS

Having defined a suite of mime types (global ones, personal ones, or via the magic file), how is this 'connected' to applications?

KFM maintains two separate application tables

It should be obvious that everything discussed so far about mimelinks is mirrored for application links. The same visual functionality, navigation, editing, and internal linking is employed. The same root caveats.

Once KFM discovers a file has a "thingo/whatsit" mimetype, it then looks up it's table of applications for the one with a 'thingo/whatsit" entry. The program associated with this <whatever.kdelnk> is executed.

MIME and 'APPLICATION' Folder Structure

EVERYTHING after /opt/kde/share/mimelnk (and separately /opt/kde/share/applnk) is one single database. KFM does NOT associate ANYTHING special about the folder names (for the purposes of the database, all folder names are stripped). The organisation of editor type applications in a folder called ~/applnk/editors/ is strictly a human convenience.

I am not advocating you ignore sensible structure when creating new mimes/applications, I am merely pointing out that there is no reason why you could not later decide to move a java editor into it's own special category. There is NO consequent editing of link information should you do so.

Enjoy.

Search