csant/log

I have been asked more than once how Opera on UNIX systems decides which applications are handling which MIME types, and which one of these is chosen as the default handler. Let me start off by saying that this is a jungle: each system, each desktop environment, and possibly each version of the environment handle it in some more or less subtly different way. Freedesktop.org has made some attempts at unifying the system of defaults, and has come some way to deciding how to allow applications to declare which MIME types they can handle - but when it came to define the defaults, unfortunately they could not yet agree. It is work in progress, and managing to have a spec for this will make things much more easy. For the time being we are parsing MIME type handlers, not protocols.

Default handlers

Opera checks the following files to find the default handlers. The XDG_DATA_DIRS environment variable tells us where to find most of those files. Typically in /usr/share/mime/ are

aliases

specifies MIME type strings that are aliases to each other;

globs

aid file for guessing MIME type based on the filename;

subclasses

defines a MIME type to be a subtype of another one, so that any handler of the supertype is also a handler for this type;

application/*.xml

XML file to describe a MIME type;

and we also parse:

mimeinfo.cache

maps MIME types to applications with no specific preference;

defaults.list

GNOME file to specify defaults;

*.desktop

desktop files are available for both applications and MIME types;

mailcap

a configuration file to map MIME types to handlers.

The upcoming kestrel version has improved handling of above resources, and will also handle:

gnome-vfs.applications

lists applications and the MIME types each one supports

kderc

provides among other things the path where to find the KDE settings (typically /etc/kderc)

~/.kde/share/config/profilerc

User specific KDE mapping of MIME types to application (and defaults)

We also parse the index.theme file to make everything look much more pretty

• Binary and source packages should be available;
  
• they should be as unpatched as possible (I don't like distros applying their own patches);
  
• it should have a bleeding edge branch with most-up-to-date packages;
  
• the package manager of the distro should be flexible enough to ideally be able to handle manual upgrades of the packages - but at least to allow the installed base to be expanded;
  

• a fast boot;
  
• lightweight system;
  
• good hardware support;
  
• good support from the community
  

On my laptop I use the Acer Hotkey driver for Linux to turn on/off the radio kill switch. I currently run acerhk-0.5.34, the latest public version. The page however seems to have been taken off the public web (anybody has any info?), so updates are not really to be expected. But…

…after kernel 2.6.19 removed the obsolete linux/config.h include, the module would not compile anymore. Many modules might run into this problem, and will need upgrading.

The old linux/config.h didn't have much necessary info anyway, so the simple patch to get this module back alive is to comment out the line

#include <linux/config.h>

in acerhk.c and just compile the module Works fine, and you have your radio kill switch button back.

Update:

The project seems to have changed location.

Intsalling Opera on test machines is easy.