Hi,

I want to change the standard application called by the maemo filemanager and browser for some filetypes/mimetypes.
Therefore I'm currently wading through the freedesktop specs and the various mime/protocol related files in /usr/share/mime and /usr/share/applications

So far most of it is clear to me. It seems the Maemo developers did mostly stick to the freedesktop guidelines and did also include some of the freedesktop cli tools for handling this.

But there is one application /usr/bin/mc-import which is also somehow involved in handling mime types and which seems to be something Maemo specific. This application is also referenced in /usr/share/applications/mc_import.desktop.

Does anybody know, what exactly this application is used for? Neither via Google, nor on maemo.org nor here on ITT I could find any reference to this.

Your best bet is to join the maemo developers mailing list and ask there. Someone from Nokia might know.

To change the default application(s) the File Manager opens when you double-tap in a file...

In X Terminal:

1- Login as root

2- Go to /usr/share/applications/

3- Edit the file: defaults.list

Hope it helps !!!

Great! Thanks for the tip!

That file is bizarre. It has all sorts of references to non-existent files, like "hildon-browser.desktop" and "hildon-mp_ui.desktop" and "hildon-image-viewer.desktop"

When I replace the goofy associations with my preferred associations, (such as changing every line that starts with "video/" to "video/<xxx> = mplayer.desktop") and try to open the file from file manager, it doesn't seem to work, even after a reboot.

That's because you need to imagine that for example the line that says:
video/x-msvideo=hildon-mp_ui.desktop
refers to: /usr/share/applications/hildon/mp_ui.desktop (shortcut to the default media player)
so "hildon-" means "hildon/" folder. "-" = "/"

to change to kmplayer for exaple you change it from:
video/x-msvideo=hildon-mp_ui.desktop to:
video/x-msvideo=hildon-kmplayer.desktop and voila!
when you try to open in file manager an AVI it will use kmplayer (if installed)...

Mime types seem to be more complex than this in Hildon... It seems to have something to do with the MIME line in the /usr/share/applications/hildon/appname.desktop file, and the DBus service file... I'm looking at the way Quiver launches from the file manager when you click on a picture, as an example.

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.

That is what I feared. I really like the idea of a 'shim', and I would gladly beta-test it, but, as I mainly just want video to launch from mplayer, I should just pester Serge to get his maemo front end to accept dbus parameters and pass them on to mplayer.

I've installed emelfm2, but it is really crowded and non-intuitive to work with. I would like something better than the default file manager, but still with a sparse, uncluttered interface and very few fancy features.

- one of the better threads i've read here on ITT lately... a shame really, as it seems like needless complication for simple app-launching? what is the possible reasoning behind this? (must read up on dbus, eh?)

- aha! one gººg search and i found it...

from:

here:


D-BUS Session Bus

Each application in the device has a well-known name. E.g.: “Browser” or “Email”. The application name uniquely identifies the application. There’s a D-BUS service for each application, derived from the application name.

Applications are executed (activated) by the D-BUS session-bus daemon. If not running, an application is implicitly activated when a message with auto-activation flag is sent to the corresponding service. D-BUS gets the binary name to execute from the corresponding D-BUS .service file. The (activation) message may also contain parameters for the application, e.g. the name of a file to open in the application. D-Bus activation guarantees that at most one instance of the application is running at a time.

If the service doesn't register within given timeout, D-BUS assumes that the service (application) process startup failed and it will kill the started process. "