qole, afaik the dbus service thing requires that the program you are associating has coded a callback to listen or get the dbus message. This pretty much limits your choices to fully hildonized applications like quiver.

I explored this aspect (with help from twaelti and tkulve) and pretty came to the conclusion that associations as handled by maemo file manager or mozilla (since they use dbus) would need a shim type program to convert this out to launch with command line parameters... or of course hildonizing the program to get that dbus callback. A shim though could act as a switchboard, registered to several mime types, receives the dbus message, and knows how to convert to command line and which program to use (either by using defaults.list or its own registry)

- 'Maemo' Hildonized apps (like image viewer/browser/pdf viewer) seem to -only- accept dbus parameters... passing on command line do nothing.
- 'Maemo' Hildonized app launchers (like file manager/browser) seem to -only- call out to programs which can accept those dbus messages.
- Quiver does both... but its rare to find these third party apps that do... if no workarounds develop perhaps it would be useful to identify those that do.
- Non-Hildonized programs can obviously launch with command line parameters
- Non-Hildonized can in theory pass parameters to hildonized apps by sending dbus messages after launching. This is sort of implemented in emelfm2 by using a sample program from tkulve which sends those dbus messages. This wont work on first launch of application. Possibly future timing (making sure app is loaded before sending dbus message) or refining the dbus message might fix this. Command line utilities dbus-monitor and dbus-send can be used to spy on this message stream.

Sad really, since many times applications crash for me using the dbus method of passing parameters... ever launched a media stream to have browser crash? I have... alot.