Notices

If I understand correctly, I should do the same for all the mimetypes that are mapped to Evince_Debian in user-mimetypes.list, to wit
with all "Evince Debian" changed to hildon-dbus-switchboard.desktop in corresponding entries in /usr/share/applications/defaults.list, and similarly for the uri-action-defaults.list (why this duplication btw?)?

Do I also understand correctly, that these manual entries are necessary for all instances where microB knows about the mimetype, and only when microB gets "unknown/unknown" dbus-switchboard looks up the mimetype itself, in which case user-mimetypes.list determines the handler defined in /usr/lib/dbus-switchboard/dbus-switch-apps.cfg. And dbus-switch-xref.cfg is finally used when dbus-switchboard cannot determine the mimetype without looking at file extensions?

What a maze!

casper27: Your rtsp stream doesn't have a clear extension; it has a long set of (probably confidential ) parameters after the .sdp, including the login information and stream type.

Perhaps I should change the system to treat protocols differently; it shouldn't even bother with file extensions if it has a recognised protocol...

EDIT: Huh, it actually does have that. I wonder why it isn't working... Debugging...

rebhana: Don't add a type to the default.list files unless you click on the file in the browser and it shows the mime type for that file. But if it recognizes the mime type, then yes, you do have to list it in the two mime type files. And no, I don't know why the duplication.

I would actually like to "break" the mimetype recognition for MicroB, so it sends everything not listed in the defaults to dbus-switchboard. I don't know how to do that, however. At least, not yet....

New version 1.2.18 fixes the protocol bug casper27 discovered.

Confirmed, rtsp streams from TVCatchup are working again with vlc - thank you!

YES!!!! I managed to beat vodafone..
I have managed to get the stream to open in VLC by tunnelling rtsp over http.

I compared the address used by the iphone stream, saw that it is an HTTP connection using port 1935. I also read up on the vlc documentation and found that it could tunnel rtsp connections over http - therefore sidestepping the blanket ban imposed by vodafone.
So.. Using the port and the tunnelling i tried the following command in dbus-switchboard:

This tells vlc to quit if it cannot connect, otherwise it stays running in the background doing nothing, tells it to use the Q key to quit (same as mplayer), and tells it to tunnel rtsp over http port 1935

I can say for certain this plays back even better than before.

I'm going to test that further, but I found that are a couple of mimetypes that MicroB detects and which therefore should be included in the defaults.lists. I'll post a list when I've checked the types of relevance to Evince_Debian and OpenOffice. Regarding OO, at the moment only the MS doc format can be opened, and not the open formats odt, ods, odp, because microB does recognize them as application/vnd.oasis.opendocument.text etc.

I actually have a perhaps more tricky problem to offer : In dbus-switchboard I would like to have the option to choose between the standard pdf reader and evince also when it is dbus-switchboard that recognizes a pdf file. Evince is more capable, but also slower, so it is certainly nice to be able to switch back and forth. And when you finally bring dbus-switchboard to the masses, the osso_pdfviewer should probably even be the default since not everybody will have qwerty12's evince (it's still only in extras-devel!).

But osso_pdfviewer is not in the list of handlers and I realized that I probably cannot so easily add osso_pdfviewer to it because osso_pdfviewer does not take parameters such as file names. I found some information on how the standard pdfviewer could be invoked explicity in this thread. One possiblity seems to be a script that invokes osso_pdfviewer through dbus, as discussed in the said thread, but this is somewhat of an eye-sore. Would you see a more elegant solution to handle osso_pdfviewer through dbus-switchboard?

EDIT2: Solved ! After a large number of trials and errors, I found that
in dbus-switch-apps.cfg gives what I was asking for!

Brilliant is all I have to say. Really works well Thanks man and thanks to qole and the others for putting so much time in made my week

Another problem:

In user-mimetypes.list we have mapped
and xrefs also maps .dvi to Evince Debian. However, dvi files (device independent LATEX output) are invariably opened by native evince, which unfortunately cannot handle them although it has dvi files under its mimetype declarations.

I even tried to enforce dbus-switchboard by entries
in defaults.list and uri-action-defaults.list, respectively. But to no avail, despite running
and rebooting.

Indeed, the entry
in /usr/share/applications/mimeinfo.cache remains and only evince gets started.

I guess I could manually modify the files of the evince package to no longer refer to x-dvi, but above all I would like to understand how I can actually use dbus-switchboard to determine which program handles what, even when several packages could do the same. I'm really lost in this mime maze! It's not that I need mime support for this file format so urgently - I used it to learn about mime and dbus-switchboard, but are now driven to the conclusion that this is totally beyond me.

qole, I attach a (gzipped) sample dvi file, in case you want to reproduce all this.

EDIT: Just noticed that /usr/share/applications/mimeinfo.cache had a time stamp from some 2 weeks ago. Just deleting the dvi related entries there solved the problem that all the other configurations didn't have any effect for that mime-type. I just wonder who is in charge of that cache as update-mime-database doesn't update it? This is like fighting a hydra!

EDIT2: Turns out that that solved my problems only partially: Local dvi files now open with Evince Debian with microB, but when opened on the web, microB says "application/x-dvi" and still only offers to save, and not to open with dbus-switchboard, despite having made entries for that type in defaults.list and uri-action-defaults.list. I now also need to supply a line
application/x-dvi=hildon-dbus-switchboard.desktop in /usr/share/applications/mimeinfo.cache. While it now works, this is completely nuts! What am I missing here? Why was that not necessary with application/postscript??

qole, why did you have to break the symlink between /usr/share/application/defaults.list and /etc/gnome/defaults.list? Wouldn't it be safer to have them remain identical?