Understanding Maemo Mime handling
 

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.

Re: Understanding Maemo Mime handling
 

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

Re: Understanding Maemo Mime handling
 

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 !!! ;)

Re: Understanding Maemo Mime handling
 

Great! Thanks for the tip!

Re: Understanding Maemo Mime handling
 

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.

Re: Understanding Maemo Mime handling
 

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)...

Re: Understanding Maemo Mime handling
 

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.

Re: Understanding Maemo Mime handling
 

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.

Re: Understanding Maemo Mime handling
 

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.

Re: Understanding Maemo Mime handling
 

- 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. "

Re: Understanding Maemo Mime handling
 

oh ye honking gods, how come this isnt clearly spelled out somewhere?!

Re: Understanding Maemo Mime handling
 

qole : i agree emelfm2 is overkill just to use as an app launcher, and yes it has its share of quirks... but god is it powerful :)

linuxauthor : you nailed it... i'd guess mainly its to enforce single instancing of applications. Any shim program would probably just allow multiple instances... user discretion would ensure you dont run out of memory by not shutting down old apps. Mplayer is easy though since exiting full screen can quit.

tso : afaik they only advocate hildon/dbus -> hildon/dbus and this is documented (in arguable clarity) as requiring changing codebase to support that callback. I am not familiar enough with dbus on regular distros to know if this is a proprietary implementation. I'd rather not be forced into this as only option for associations although i see possible benefits of such an interprocess communication (IPC) mechanism. Most existing source code that i have seen (which has or could be) ported to maemo doesn't support dbus messages.

Imagine how much better and versatile your device could be if you could associate these non dbus apps...

If someone can figure out how to successfully launch from cli sending just dbus messages / script files, then the possibility exists to replace the file manager with a different file manager which can do both (as opposed to middle-man shim). Or the middle-man could be reverse shim-scripts which convert the opposite direction (shell out cli which converts to dbus).

Re: Understanding Maemo Mime handling
 

MaemoN00B: Your method, once I understood how the whole "hildon-" thing works, gets me part of the way there. I made a usr/share/applications/hildon/mplayer-CLI.desktop file for mplayer, referred to it in that file you mention, and I get "CLI MPlayer - loading" in the top right of my screen, but that's all.

I think, as pipeline says, hildon apps simply do not pass filenames to the associated apps except through this dbus system, so that rules out command-line apps like mplayer.

Does this maemo kmplayer app use dbus?

Interesting update: My attempt only got that far as long as I had an X-Osso-Service line in my mplayer-CLI.desktop file, and that method, as we have determined, is a no-go for non-hildon apps. As soon as I removed the X-Osso-Service line, file manager just throws up its hands and doesn't know what to do with video at all.

Re: Understanding Maemo Mime handling
 

iirc dbus is open source, but its also a fairly recent addition to the overall "ecosystem". more "mature" code do not have the required support built in...

Re: Understanding Maemo Mime handling
 

It looks like kmplayer will do what I want it to. From the garage home page:

"Video playback using osso-media-server and MPlayer, with fullscreen and sub-rectangle (using SMIL) support. Be patient though with initial video start"

So KMPlayer acts like a shim between mplayer and the wacky hildon-osso dbus system. I'll download and experiment.

Another interesting thing about kmplayer is that it plays flash outside the browser ("using the libflash browser plugin"), which opens possibilities for flash games; perhaps even making application menu items for flash games is possible?

Re: Understanding Maemo Mime handling
 

Nice to know... i guess so far that makes quiver and kmplayer so far which support dbus... too bad neither are python because it that would make for good starting point to build a universal shim from since the codes right there (and editable) on device... very important for patching with new apps.

As for flash games, this could work in theory. I tried it (with kmplayer) for two different swf flash files and it crashed in the libflashplayer.so lib though. But it did seem to get the command line parameters which would be missing piece to integrating swf files/apps into maemo menu system.

Re: Understanding Maemo Mime handling
 

The kmplayer web page says, "The osso-media-server control, done by using d-bus, is in kmplayerprocess.cpp" so maybe someone who knows C can get the needed code from there?

Re: Understanding Maemo Mime handling
 

make that c++...

Re: Understanding Maemo Mime handling
 

Ok i got a working demo of this in python which is best language to use... at least for now in the hack/retry/hack/retry... stage

First sample just implements 'torrents' to transmission program but you can hack in your own associations really easy and it will support pretty much anything.

So i've got this simple python script which i put into /usr/bin/dbus-switchboard.py (set execute permissions on this file) :
And a dbus service in /usr/share/dbus-1/services/dbus-switchboard.service :
I've also got a .desktop file in /usr/share/applications/hildon/dbus-switchboard.desktop which you will don't seem to need to change :
And not sure if its needed but i edited the /usr/share/applications/defaults.list add mime type link as well with the lines :
- You will probably need to reboot for the dbus service settings to take effect -

Ok this solution is still rough and you should probably load xterm and run the python from there (at least while we are debugging) to see console messages. But it does seem to work and launch that python prog even when you dont.... its just invisible.

So open xterm and then run /usr/bin/dbus-switchboard.py and leave it running and you can browse web and download ('open') a torrent and it will load in transmission. I assume same would work for file manager but benefit for that app is from browser.

I got working for avi files to launch mplayer from file manager but i need to fine tune/fix up the parameter since if the filename has a space in it mplayer doesnt like it.

Eventually i'm hoping a python expert can pick this up and design a nice screen which lets you configure which apps to launch for each filetype. The part where you bind mime types to dbus-switchboard would be manual but the part where you bind dbus-switchboard to 'sinks' or applications could be packaged into gui program.

Re: Understanding Maemo Mime handling
 

Ok I built a deb installer for the first version which will support avi files and torrent files.

Install this :
http://wardenclyffetower.com/MaemoFi...-1.1.3.all.deb

Then edit the /usr/share/applications/defaults.list file (as root) and change relevant mime types such as :
video/x-msvideo=hildon-dbus-switchboard.desktop
application/x-bittorrent=hildon-dbus-switchboard.desktop

There is issue an issue with file names containing certain special symbols, currently i support the special symbols '[' ']' and '+' ... the other special symbols will show up as char codes like %5B %5D so if it wont launch, look for that. Unless someone knows a better way i guess i will just convert a bunch of common symbol codes in later versions.

I didn't need to reboot after installing this... not sure if you will need to or not.

If you see popup notices but your file doesnt launch then load the dbus-switchboard.py from xterm, try again, and read xterm console for info which might help.

Re: Understanding Maemo Mime handling
 

"dbus-switchboard loading..."

"MPlayer launching..."

Hey presto! There's my video.

Thanks, pipeline. No reboots or hassles involved. Just installed the .deb, edited the defaults.list and it worked.

As a side note, the built-in media player definitely handles .mp4 video better than mplayer. I was a bit shocked to discover that.

Re: Understanding Maemo Mime handling
 

Adding the following line to dbus-switchboard.desktop seems to speed up the process:

StartupNotify=false

Re: Understanding Maemo Mime handling
 

not sure, but i suspect that there may be a dedicated decoder chip in there somewhere. something the mplayer cant access but the built in one maybe can.

this is also why i think nokia opposed going for ogg as a default web media, no hardware decoders...

Re: Understanding Maemo Mime handling
 

I just went to the garage page, the mplayer dev admits he hasn't optimized mplayer for .mp4 video yet, and that it doesn't handle it well, although he says that it is "fixed in SVN" so I guess we'll see an improvement in the next version.

Re: Understanding Maemo Mime handling
 

Thanks for StartupNotification setting... disabling hides this ugly part from user (as it should be). Not sure it speeds up much or any but its less distracting.

I guess ican add mp4 since its up to the user has to elect (by editing defaults.list) to have that mime type associated with dbus-switchboard anyways.

Re: Understanding Maemo Mime handling
 

now to get some kind of gui bolted onto it ;)

Re: Understanding Maemo Mime handling
 

Ok, more news.

I've been experimenting with Orb and getting video streaming working. The problem is that I can't stream ASX (WMV) files to mplayer, because Media Player always intercepts the call from the browser, and then, if I can get mplayer to take over using dbus-switchboard.py, mplayer doesn't understand the .asx file format!

So I embarked on my first jaunt into python programming, and I tweaked dbus-switchboard.py to open up an asx file and find the wmv file inside. Here's my new code (note the first two lines and the last line are old code, just to give context: )

Oh, I almost forgot, I also had to add the following two import lines at the top of the program (to be able to read files and use regular expressions):
I found I also had to remove a bunch of mime types from mp_ui.desktop (pretty much anything starting with 'video/x-ms-') to get dbus-switchboard.py to take the asx file at all. I also put a few extras into defaults.list, but I don't know if that had any effect.

The result? I can click on a "Play" link on my Orb page, and it will play in mplayer! The video is a bit "smeary," because I think mplayer is getting some frames that it doesn't know how to decode, but that's better than the built-in Media Player's halting, freezing, attempts to play RealMedia streams via Orb.

Re: Understanding Maemo Mime handling
 

I tried to add .flv (Flash video, like from YouTube) to the recognized mime types, but no luck. I added "video/x-flv" to the defaults.list, but the file manager still sees it as an "unknown file type". Anybody got any ideas?

If I choose "dbus switchboard" from the list of applications, everything works well (I added .flv to dbus-switchboard.py), but I can't figure how to make .flv files recognized by maemo.

EDIT: It looks like .flv files are being labeled as "application/octet-stream" so I just pointed application/octet-stream to dbus-switchboard, and now ALL unknown file types are being piped through there. Now Flash videos play from File Manager, but clicking on other unknown files does absolutely nothing... This is looking more and more like we should make this shim into a full-powered mime handler; if dbus-switchboard doesn't recognize the file type, ask the user what to do, and, unlike the current mime type handling (ask every time) REMEMBER what the user chose.

Re: Understanding Maemo Mime handling
 

Thanks for info about parsing asx... python isnt so bad (and great for stuff like this). I didnt know mplayer cant handle those asx 'wrappers' natively though.. i guess that makes sense though.

Good ideas on both counts, yes this could grow to be rather elaborate. I was planning on keeping the switchboard itself simple but i like idea of simple picklist when no association has been made yet... and a separate app to let you manage them all at once in visual app... working on common configuration file.

In order to be general purpose i need to copy sample to pass params to hildon app (acting as intermediary). That way dbus-switchboard can let you 'sink' the file to either a command-line app -or- dbus/hildon app.

So first guess i'd need to set up simple appregistry (like Name, DBUS-Support, mime-type, command-line) :
'mplayer def settings', 'false', '', '/usr/bin/mplayer %s'
'Media Player', 'true', 'whateverineedtopass', ''

And simple cross-ref config file (mimetype/sink) :
'video/x-flv', 'mplayer def settings'
'application/x-bittorrent', 'transmission'

With that setup then your newly added logic can check to see if its mplayer and if so it can handle your 'custom logic' where for Media Player it might not need to.

I knight you 'python-veteran' (btw im newb) and conscript you into the service :) I'm splitting time right now but the next thing to tackle is probably config files in /home/user/.somewhere and reading them into object array. Maybe if i can get that set up it will be easier for group contribution in permanent way.

Re: Understanding Maemo Mime handling
 

Hello.
Pipeline: Can you add pdf handling (with evince) to you package? It will be very usefull for me(I hope, not for me only :) ). Thank you. :)

Re: Understanding Maemo Mime handling
 

I have updated dbus-switchboard to version 1.1.0 which you can download here :
http://wardenclyffetower.com/MaemoFi...-1.1.3.all.deb

This release :
Adds two new cfg files in /home/user
Adds qole's custom asx handler
Adds evince and comix (neither tested)

New config files :
/home/user/.dbus-switch-apps.cfg : this contains registry of all dbus-switchboard apps

/home/user/.dbus-switch-xref.cfg : this contains crossref matching file extension to app

You still need to register the mime-types in defaults.list. Find the mime type in defaults.list and set it to = hildon-dbus-switchboard.desktop

If you try to associate a mime type with no previous entry in defaults.list and you want to use that association from file manager (and not web browser) then there might be another master-list mime config file it needs to be added to. Transmission (application/x-bittorrent) works because the web server tells browser what the mime type is... but that info is lost if you save the torrent and open from file manager... so probably another config file for those cases.

The .dbus-switch-apps.cfg file will be the 'master list' with any possible apps we might want to associate. Experiment with these files and then let me know of any new apps or 'profiles' you want added... so for like mplayer maybe you want multiple profiles with different launch settings.... mplayerStreaming, mplayerMADaudio, etc

The .dbus-switch-xref.cfg will be custom per user and used in future by a UI application to choose which app (if multiple choices) the file should be sent to.

Re: Understanding Maemo Mime handling
 

WOW!
This sounds like the answer to my problem illustrated >>HERE<<

If so, is there a step by step available to associate WMV files I encounter with the web browser so that MPlayer opens instead of media player?

I'm sure it is in this thread somehow however, I'm slow like that...

Perhaps a summary then?

Where to find the file to edit.

How to access it and edit it.

What specific line should be edited with what specific new info.

Thanks for your time, output, and eventual patience. :)

Re: Understanding Maemo Mime handling
 

possibly... but doesnt seem to work at the moment so i need to research more

this seems different in that its not so much a mime type as a protocol type mms://

if i click on details it tells me no mime/type so i need to figure out how it determines who gets protocol handlers

if anyone else knows feel free to chime in :) otherwise i will test more later

Re: Understanding Maemo Mime handling
 

BDIFD ("Boy, Do I Feel Dumb"):

playlist formats (like .asx and .pls) are handled in mplayer. You just have to add the -playlist parameter in front of the %s. No fancy file parsing necessary. So you can scrap my custom .asx handler and make it just like .avi, just change it to

EDIT: I installed the latest dbus-switchboard, removed the custom handler, and edited the new config files as follows:

.dbus-switch-apps.cfg, added the following line:
.dbus-switch-xref.cfg, added the following lines:
Also, I'm changing my mind about mplayer performance with wmv streams. I am getting lots of "J-type picture is not supported" errors when trying to play those streams, while the realmedia streams seem to play more cleanly in Media Player.

Re: Understanding Maemo Mime handling
 

I copied the mms:// link from YoDude's TV Station website, and then opened a terminal and typed, "mplayer <pasted link>" and it played.

So the next test was to paste the mms:// link into the address bar of the browser and change the "mms://" to "http://". Now I get a dialog box that says "dbus-switchboard" handles this type, and when I click on "Open," mplayer plays the file.

So, a quick and dirty fix is either a bookmarklet or greasemonkey script that changes all "mms://" links to "http://" links. Combine this with dbus-switchboard, and your problem is solved. Well, except for the fact that .wmv looks like crap on maemo-mplayer due to the error I mentioned above.

Anyone want to write the javascript?

Re: Understanding Maemo Mime handling
 

Thanks fellas (pipeline and qole) for running this down for me.

So it sounds like for now, running dbus-switchboard, GreaseMonkey, and a yet to be written script is the way to go.

Could a future change in dbus-switchboard also accomplish this?

HOWTO Use Pipeline's DBus Mime shim
 

Ok, I wrote the Javascript, it works, so here's a sketchy HOWTO:

Before you start, you need:

• A way to become root
• Python
• Text editor (leafpad)
• Pipeline's dbus-switchboard package
• Greasemonkey Browser Extension

1. Install dbus-switchboard
2. Edit /usr/share/applications/hildon/mp_ui.desktop, remove the line beginning with MimeType
3. Edit /usr/share/applications/defaults.list, change (or add) the following lines from hildon-mp_ui.desktop to hildon-dbus-switchboard.desktop:
   
   Code:

   ---

   video/avi=hildon-dbus-switchboard.desktop
video/x-ms-asf=hildon-dbus-switchboard.desktop
video/x-msvideo=hildon-dbus-switchboard.desktop
video/x-ms-wmv=hildon-dbus-switchboard.desktop
video/x-ms-wm=hildon-dbus-switchboard.desktop
video/x-ms-asf-plugin=hildon-dbus-switchboard.desktop
video/x-ms-wvx=hildon-dbus-switchboard.desktop
video/x-ms-wmx=hildon-dbus-switchboard.desktop
application/x-ms-asx=hildon-dbus-switchboard.desktop
application/octet-stream=hildon-dbus-switchboard.desktop

   ---

   (I have more, but these ones should ensure that all .wmv video plays in mplayer.)
4. Install my Greasemonkey script.

EDIT: I uploaded my tiny script to userscripts.org. Click on the link above to install it.

Re: Understanding Maemo Mime handling
 

Could I use this to call my custom call.sh for tel: links from microb? Sweet!

Re: Understanding Maemo Mime handling
 

Damn, looks like URI handling is similar, but different... any chance in getting the URI handler code into dbus-switcher? It would also alleviate the need to use greasemonkey for mms: as well ( if I'm seeing this right ).

Re: Understanding Maemo Mime handling
 

Pipeline, could you please add the mp_ui.desktop without the MimeType line to your .deb? I'm not as sure about the defaults.list file; I think it would be a good idea, but there may be side effects...

If those two files are updated with the .deb, then the user doesn't have to do anything except change the two config files in the home dir.

The config files should probably have an example of a file type that is associated with the built-in Media Player, just so it is clear how to associate files to a hildonized, non-CLI app via dbus-switchboard.

Please post your results here. I'm curious to find out! Could you link to the thread where you discuss this custom script?