Mailing List Archive: Maemo: Developers

passing arguments to hildon applications

Index | Next | Previous | View Threaded

advax at triumf

May 27, 2008, 2:29 AM

Post #1 of 13 (1439 views)
Permalink

passing arguments to hildon applications

What I'm really trying to do is click on an MPEG URL in
the N810 browser and have Mplayer play the video.
Which is something I thought I'd known how to do for years -
make an entry in /etc/mailcap like
video/mpeg; mplayer %s
or to handle a playlist, like .WVX
video/x-ms-wvx; mplaylist %s
where mplaylist is a script "mplayer -playlist $1"

But although the Firefox microbrowser on the N810 reads /etc/mailcap
(and /home/user/.mozilla/microb/mimeTypes.rdf) it ignores them.

It seems to use entries in /etc/gnome/defaults.list to start
things like the PDF viewer, Nokia media player etc., provided there
are desktop and service files for them.

So I can add a new MIME type and have osso_notes open it by adding
a line like:
foo/bar=hildon-osso_notes.desktop

But if I make an entry for mplayer, or mplaylist, it doesn't work.
There is no argument passed - mplaylist starts, but does not play
anything.

Conversely, if I try to start osso_notes or osso_pdfviewer from the
command line, e.g.
$ osso_pdfviewer foo.pdf
as I would normally start Xpdf or Acroread, it starts up with
a blank document. Passing a --help option has no effect, either.

I presume someone decided to abandon 20 years of common Unix practice and
do things differently. Which is somewhat annoying, to say the least.
How the ** is this supposed to work - i.e. launch mplayer from the
browser or osso_pdfviewer from the command line ? ?

--
Andrew Daviel, TRIUMF, Canada
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

josh.soref at nokia

May 27, 2008, 2:59 AM

Post #2 of 13 (1401 views)
Permalink

RE: passing arguments to hildon applications [In reply to]

Andrew Daviel <advax[at]triumf.ca> wrote:
> What I'm really trying to do is click on an MPEG URL in
> the N810 browser and have Mplayer play the video.
> Which is something I thought I'd known how to do for years -
> make an entry in /etc/mailcap like
> video/mpeg; mplayer %s
> or to handle a playlist, like .WVX
> video/x-ms-wvx; mplaylist %s
> where mplaylist is a script "mplayer -playlist $1"
>
> But although the Firefox microbrowser on the N810 reads /etc/mailcap
> (and /home/user/.mozilla/microb/mimeTypes.rdf) it ignores them.

> It seems to use entries in /etc/gnome/defaults.list to start
> things like the PDF viewer, Nokia media player etc., provided there
> are desktop and service files for them.
>
> So I can add a new MIME type and have osso_notes open it by adding a
> line like: foo/bar=hildon-osso_notes.desktop
>
> But if I make an entry for mplayer, or mplaylist, it doesn't work.
> There is no argument passed - mplaylist starts, but does not play
> anything.
>
> Conversely, if I try to start osso_notes or osso_pdfviewer from the
> command line, e.g. $ osso_pdfviewer foo.pdf
> as I would normally start Xpdf or Acroread, it starts up with
> a blank document. Passing a --help option has no effect, either.
>
> I presume someone decided to abandon 20 years of common Unix practice
> and do things differently. Which is somewhat annoying, to say the
> least. How the ** is this supposed to work - i.e. launch mplayer from
> the browser or osso_pdfviewer from the command line ? ?

Yep. I think it's called platform integration. You probably need to
use/support dbus.

Although in the case of mplayer, you're probably running afoul of this
other bit that I'm about to mention

There's a lot of hackery foating around. You don't want to read it (it
took me around 20 pages of cross reference reading to compile what is
below).

First for a hard coded list of mime types, we'll pass urls instead of
downloading files.
^ you may hit this ^

The "mime type" as I understand it is something which gnome-vfs decides,
and isn't necessarily related to the actual mime type of the object
(this is always fun).

Assuming we go on the "normal" path, we call (and you could determine
this by instrumenting gtk, so this is not a secret...)

gnome_vfs_get_mime_type_from_uri
gnome_vfs_mime_get_default_application
hildon_mime_open_file_with_mime_type * DBUS, yay
If that fails, we might call:
hildon_mime_open_file * DBUS, yay

http://timeless.justdave.net/mxr-test/chinook/ident?i=gnome_vfs_get_mime
_type_from_uri
http://timeless.justdave.net/mxr-test/chinook/ident?i=gnome_vfs_mime_get
_default_application
http://timeless.justdave.net/mxr-test/chinook/ident?i=hildon_mime_open_f
ile_with_mime_type
http://timeless.justdave.net/mxr-test/chinook/ident?i=hildon_mime_open_f
ile

Fwiw, at the present time, video/x-ms-wxv is among the "hacks". These
"hacks" were requirements. We're hoping that some future version may
lose some or all of these hacks. But don't hold your breath, I've been
holding my breath for two years and only just now got a sign that maybe
something might happen eventually.

As for what you can do realistically.
You can hack the binary to have a different hard coded list of mime
types oediv/* and oidua/* would probably work wonders. The browser
itself doesn't want this code so afaik binary hacking those away
shouldn't do much harm :)

You can replace the implementation of gnome_vfs_get_mime_type_from_uri
so that it never returns the hard coded types that are causing you pain.
Returning oediv/* and oidua/* instead would of course work.

You might be able to find a text file or something like one which is
used by gnome_vfs_get_mime_type_from_uri so that you don't actually have
to change any binaries or source files.

The file was probably called "mediaplayer-ui.xml" I'm not sure about the
on device name (cross reference covers sources, not deliverables).

It should be sufficient to change that file to use noitacilppa/x-ms-asx
and friends in their corresponding type= lines.

There will probably be a diablo xref up at some point after diablo is
released. Obviously it won't happen before the release. But the APIs
you're interested are not going to have changed. And you won't see new
sources from the browser integration so the links above should be
sufficient.
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

eero.tamminen at nokia

May 27, 2008, 3:04 AM

Post #3 of 13 (1399 views)
Permalink

Re: passing arguments to hildon applications [In reply to]

Hi,

ext Andrew Daviel wrote:
> What I'm really trying to do is click on an MPEG URL in
> the N810 browser and have Mplayer play the video.
> Which is something I thought I'd known how to do for years -
> make an entry in /etc/mailcap like
> video/mpeg; mplayer %s
> or to handle a playlist, like .WVX
> video/x-ms-wvx; mplaylist %s
> where mplaylist is a script "mplayer -playlist $1"
>
> But although the Firefox microbrowser on the N810 reads /etc/mailcap
> (and /home/user/.mozilla/microb/mimeTypes.rdf) it ignores them.

I think Browser has some special code to handle issues related
to streamed vs. local video data as some codecs support streaming,
some only local play. ...and that's why it doesn't use mailcap.
It's just a guess though.

> It seems to use entries in /etc/gnome/defaults.list to start
> things like the PDF viewer, Nokia media player etc., provided there
> are desktop and service files for them.
>
> So I can add a new MIME type and have osso_notes open it by adding
> a line like:
> foo/bar=hildon-osso_notes.desktop
>
> But if I make an entry for mplayer, or mplaylist, it doesn't work.
> There is no argument passed - mplaylist starts, but does not play
> anything.
>
> Conversely, if I try to start osso_notes or osso_pdfviewer from the
> command line, e.g.
> $ osso_pdfviewer foo.pdf
> as I would normally start Xpdf or Acroread, it starts up with
> a blank document. Passing a --help option has no effect, either.
>
> I presume someone decided to abandon 20 years of common Unix practice and
> do things differently. Which is somewhat annoying, to say the least.
> How the ** is this supposed to work - i.e. launch mplayer from the
> browser or osso_pdfviewer from the command line ? ?

Apparently PDF viewer listens only D-BUS for the new files.

Just use mime summon utility from Tuomas:
https://bugs.maemo.org/attachment.cgi?id=687

And yes, there should be xdg-mime-utils package that provides
something like this as the standard xdg-open utility[1], I think
there's a bug about that in maemo Bugzilla... If you find it,
please vote it.

- Eero

[1] http://portland.freedesktop.org/xdg-utils-1.0/xdg-open.html
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

advax at triumf

May 28, 2008, 1:02 AM

Post #4 of 13 (1382 views)
Permalink

RE: passing arguments to hildon applications [In reply to]

josh.soref at nokia

May 28, 2008, 1:38 AM

Post #5 of 13 (1387 views)
Permalink

RE: passing arguments to hildon applications [In reply to]

On Tue, 27 May 2008, josh.soref[at]nokia.com wrote:
> Fwiw, at the present time, video/x-ms-wxv is among the "hacks". These
> "hacks" were requirements. We're hoping that some future version may
> lose some or all of these hacks. But don't hold your breath, I've
> been holding my breath for two years and only just now got a sign
> that maybe something might happen eventually.

Andrew Daviel <advax[at]triumf.ca> wrote:
> As I recall, these "playlist" content-types such as WXV, WXA and
> Realmedia RAM are required because the browsers do not
> understand RTSP URLs.

I don't want to try to dig through my memory for why they were created.

Our browser has *different* hacks for rtsp and similar urls.

Actually, I can say for certain that feed: was created exactly for the
opposite reason.

Web servers wanted to ensure that some other application safely got a
url.

> So there's a short text file containing the URL of the
> stream.

Sadly from reading bugs, it seems that one microsoft mime type can mean
either a stream or a playlist. I can't remember if this was by design or
simply because the microsoft plug-in was tolerant and web sites were
lazy.

> For a video file available via HTTP,
> using the playlist will let Mplayer stream it via HTTP,
> otherwise you have to wait for the entire file to download.

Our hacks are basically designed to address this unfortunate standard
behavior for the non playlist case if you're using the normal plugin
path.

It of course doesn't work correctly for mplayer (although in theory it
could work as well as it does for the standard player).

and it doesn't always work properly in general...

> It may be a hack, but I'm not sure how you'd get around it.

Well, atm the browser has logic that should be in a plugin. How the
plugin should be written should not be the browser team's problem :).

I explained that when I first arrived, and maybe someday that might be
the way it is.

For people curious about NPAPI, the browser will give you a url and a
chance to receive the data. You can choose to let the browser stream it
to a file, feed it to you piecemeal, or not download it.

> At one time I thought there was a mailcap variant that caused Netscape
to
> pass a URL to the helper application rather than downloading the file
and
> passing the filename.

There is (%u), support for this has been poor for years. I can't
remember how well n4 supported it, but generally speaking Mozilla
support didn't exist until fairly late (iirc bz tried to add some
support for it).
http://www.spinnaker.de/mutt/mailcap has an example

The problem is that by the time you have a mime type, the browser also
already has a stream of the file, and if it's a one time stream or a
stream guarded by authentication, passing the url to someone else means
paying twice ($+$) and possibly not getting anything at all ($ ->
/dev/null; 0 -> /dev/audio).

> Or I guess you write a browser plugin.

We have a strange browser plugin. Given the choice of this or a normal
browser plugin, I'm hoping to get a normal one.

> I prefer an external helper that doesn't take the browser with it when
it
> crashes...

There are a number of strategies, but in the end, you'll lose.

<audio> and <video> are coming to beta browsers near you by the year's
end.

* This is *not* a commitment by the microb team to include such a
feature, merely a statement that prereleases of Safari, Firefox, and
Opera will all include this feature in the near future. I can't predict
when MicroB might get such a feature (we obviously need it for
compatibility reasons).

Audio processing can be done out of process, a plugin only really needs
to accept a stream and set it to a different process for handling. It
shouldn't even need to do much in the way of parsing. It *should* be
possible for a couple of teams to write safe plugins which perform this
sort of out of process implementation.

There are a number of projects to do things like this, if only to enable
64bit browsers to host 32bit plugins, or for Qt based browsers to host
Gtk based plugins.

Actually, as far as browser crashes, diablo includes a feature such that
the ui doesn't die when the engine crashes. It's not full sessionstore
ala firefox, but we hope you'll like it.
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

advax at triumf

May 28, 2008, 1:38 AM

Post #6 of 13 (1381 views)
Permalink

Re: passing arguments to hildon applications [In reply to]

On Tue, 27 May 2008, Eero Tamminen wrote:

> I think Browser has some special code to handle issues related
> to streamed vs. local video data as some codecs support streaming,
> some only local play. ...and that's why it doesn't use mailcap.
> It's just a guess though.

Mailcap worked since MIME was invented, in Mosaic through Netscape,
Mozilla and Firefox 2. I have't tried Firefox 3 on my desktop (too old; I
don't have the new libraries..). Usually streams are handled by using
a playlist file containing the stream URL, so the browser downloads the
playlist then hands it to the helper, which starts the streaming client.
I have some ugly Perl script on my desktop to handle Quicktime, as the
playlist type and extension (MOV) are the same as for the media, but the
other types (Windows Media, Realmedia) are distinct so it just needed a
line of bash.

Which reminds me - I was meaning to try my voicemail from our PBX
webserver (I use realplayer on audio/wav on my desktop), and I could not
get the N810 tablet to play CBC Radio's live streams. I think they
started using Windows media, and for that I need Mplayer to work.

I was looking at streaming a few months ago - Mplayer and RealPlayer will
accept media streamed over HTTP, getting the required data rate by using
internal buffering and doing GETs when the buffer gets empty.
For RTSP, the server needs to understand the media format in order to
extract the required data rate etc., so certain servers will stream only
certain kinds of media. Probably why it's not so popular compared to
HTTP, where you put anything you like online as long as you have a
plausible content-type, or application/binary to let users download it
and figure it out later.

> Apparently PDF viewer listens only D-BUS for the new files.

Bah! I hate GUI file selectors ...
$ ls -t *foobar*pdf clickclick-click cut/paste
$ xpdf latestfoobarthisweek.pdf

cf. waiting for some app to paint icons for all 2300 files in the
current directory (or worse, some other directory) so that I can try and
eyeball the one I want by making tiny mouse movements.. although, on the
tablet without a proper keyboard, and with not so many files, there's
something to be said for a GUI.

>
> Just use mime summon utility from Tuomas:
> https://bugs.maemo.org/attachment.cgi?id=687
>

I built that, and it doesn't crash :-7 but it doesn't pass the file,
either. osso_pdfviewer starts up with a blank page.

--
Andrew Daviel, TRIUMF, Canada
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

eero.tamminen at nokia

May 28, 2008, 2:05 AM

Post #7 of 13 (1389 views)
Permalink

Re: passing arguments to hildon applications [In reply to]

Hi,

ext Andrew Daviel wrote:
>> Apparently PDF viewer listens only D-BUS for the new files.
>
> Bah! I hate GUI file selectors ...
> $ ls -t *foobar*pdf clickclick-click cut/paste
> $ xpdf latestfoobarthisweek.pdf
>
> cf. waiting for some app to paint icons for all 2300 files in the
> current directory (or worse, some other directory) so that I can try and
> eyeball the one I want by making tiny mouse movements.. although, on the
> tablet without a proper keyboard, and with not so many files, there's
> something to be said for a GUI.
>
>>
>> Just use mime summon utility from Tuomas:
>> https://bugs.maemo.org/attachment.cgi?id=687
>>
>
> I built that, and it doesn't crash :-7 but it doesn't pass the file,
> either. osso_pdfviewer starts up with a blank page.

I looked into that and fix seems to be simple. Add a sec or two wait
before exiting the main(). D-BUS seems to do something funky if sender
exits before the message is forwarded to the receiver.

- Eero
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

advax at triumf

Jun 5, 2008, 12:48 PM

Post #8 of 13 (1267 views)
Permalink

RE: passing arguments to hildon applications [In reply to]

(brief hiatus while I was distracted by my tablet battery connections
shaking loose and causing random reboots )

On Wed, 28 May 2008, josh.soref[at]nokia.com wrote:

Thanks for the explanations!

> It of course doesn't work correctly for mplayer (although in theory it
> could work as well as it does for the standard player).

Here's hoping someone more skillful than myself will fix up mplayer for
the tablets :-) It's faster than the default player and handles more
media.

> <audio> and <video> are coming to beta browsers near you by the year's
> end.

:-)

I'd like mailcap to work as a fallback; it's simple, I understand it, and
it's been standard in Unix for years. Apart from the streaming media
playlists, I have entries on my desktop for things like Xfig, LaTeX DVI,
PostScript, Excel etc. while installers for things like Java Web Start
assume they can add mailcap entries.

Any application specifically written for the tablet would use DBUS, but
we might still port desktop applications which run from the command line.

--
Andrew Daviel, TRIUMF, Canada
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

josh.soref at nokia

Jun 5, 2008, 12:59 PM

Post #9 of 13 (1269 views)
Permalink

RE: passing arguments to hildon applications [In reply to]

Andrew Daviel wrote:
> I'd like mailcap to work as a fallback; it's simple,

Kinda, it's not so simple (see below)

> I understand it, and it's been standard in Unix for years.

It's actually been poorly supported/unsupported for years.

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_des
c_type=allwordssubstr&short_desc=mailcap&long_desc_type=substring&long_d
esc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_ty
pe=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&em
ailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailrepo
rter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bu
g_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order
=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

https://bugzilla.mozilla.org/buglist.cgi?bug_id=83305,115041,120380,1627
42,173106
https://bugzilla.mozilla.org/show_bug.cgi?id=83305 Add correct
parsing/spawning of handlers from mailcap entries
https://bugzilla.mozilla.org/show_bug.cgi?id=115041 support %u in
mailcap helpers
https://bugzilla.mozilla.org/show_bug.cgi?id=120380 needsterminal
flag in mailcap must be respected
https://bugzilla.mozilla.org/show_bug.cgi?id=162742 Helper
Applications doesn't prepopulate based on mailcap
https://bugzilla.mozilla.org/show_bug.cgi?id=173106 copiousoutput
ignored in mailcap

I think this doesn't include the fairly important bug about file handles
not being closed before helper applications are spawned.

> Apart from the streaming media playlists,
> I have entries on my desktop for things like Xfig,
> LaTeX DVI, PostScript, Excel etc. while installers
> for things like Java Web Start
> assume they can add mailcap entries.

I'm not knocking mailcap. I happen to think it's nice in theory too.

But in practice, there are a lot of problems, a number of which are hard
if not impossible to solve properly.

> Any application specifically written for the tablet would use
> DBUS, but we might still port desktop applications which run
> from the command line.

Someone should write a dbus wrapper thing....

But yes, gecko kinda supports mailcap and microb or tablet-browser
breaks it. Sorry about that.
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

josh.soref at nokia

Jun 13, 2008, 8:21 AM

Post #10 of 13 (1173 views)
Permalink

RE: passing arguments to hildon applications [In reply to]

ext Andrew Daviel <mailto:andrew[at]andrew.triumf.ca> wrote:
> On Thu, 5 Jun 2008, josh.soref[at]nokia.com wrote:
>
>> It's actually been poorly supported/unsupported for years.
>
> How hard can it be .. download a file to a temporary
> directory, spawn an
> application and tell it the filename. It worked in Mosaic, it
> works in
> Lynx. (never mind, I'm not sure I really want to know ...)

Go read the spec. some of the handlers want urls not files.

Now here's a simple problem:

How do you know which handler to pick?
Oh, you check the mime type.

How do you find the mime type?
Oh, you download the file.

What if the file is behind a one time token?
Oh, you're in trouble.

What if the file requires a cookie?
Oh, good luck passing that url to a handler.

Now, if you only care about the simple file cases, then yeah, that's
almost supported by most things.
But the spec supports all sorts of fun bits.

>> Someone should write a dbus wrapper thing....
>
> I found one (Eero told me how to make it work).

Yeah, I was hoping someone would include the name (I know it's in the
archives), as someone else asked me about it for some other purpose
yesterday.

> I'm not sure if I can pass an argument in a Dbus service
> record (probably not; in which case I'd have to create a
> separate wrapper for each MIME type, or get a name
> from a symbolic link or something).

> But in reality I'm not that likely to want to port Xdvi or
> Xfig to the tablet; most documents are saved in PDF.

> Mplayer on the other hand would be nice to have -
> preferably with a robust plugin that would play those
> Hollywood trailer embedded WMV movies or streaming media from CBC.ca

Personally, I've tried to suggest that people get totem or a similar
proper NPAPI plugin configured.

The browser's default plugin can be disabled from the mangify button in
the toolbar, which means it really shouldn't be too hard.

The only trick is deciding how much integration you want w/ the system
components (I'd suggest none).

What I've suggested internally is that the idea media plugin would
basically support streaming and pass the data to an out of [browser]
process which would handle the media playback. Whether it sticks ui
controls into the browser or just has a button which brings the media
player forward is not my problem :).

From playing w/ flash movies on my mac w/ two displays, I'm actually
fairly annoyed w/ them... Because they have this full screen button,
which will full screen on the proper display (aux), but when I click on
another application, the full screen mode is discarded. So I can't
actually watch a full screen video while using my computer's primary
display to do work ....

I mention this because I think wanting to full screen videos is a fairly
common task, and bad implementations, especially for embeddings will
result in unhappy users. Of late, I can't really think of many cases
where I actually need to be able to see a video and do something else on
my tablet at the same time, and in the cases when I do, I'm fairly
certain that having them fixed in the browser's frame will not agree w/
me (iow, I'd rather the video float above the browser, so that I can
scroll around the page while "watching" the video).

> (they dropped RealPlayer from a lot of the site)

:(

> - on my desktop I end up doing things in Firefox like
> Tools/PageInfo/Media, clip the media URL and give it
> to mplayer on the command line - ugly, but usually works.

Heh.
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

advax at triumf

Jun 22, 2008, 4:29 PM

Post #11 of 13 (1054 views)
Permalink

RE: passing arguments to hildon applications [In reply to]

On Fri, 13 Jun 2008, josh.soref[at]nokia.com wrote:

>>> Someone should write a dbus wrapper thing....
>>
>> I found one (Eero told me how to make it work).
>
> Yeah, I was hoping someone would include the name (I know it's in the
> archives), as someone else asked me about it for some other purpose
> yesterday.

I realize now that the wrapper I have is not what I need for this. It's
still useful - lets one run the PDF viewer or media player from the
command line, e.g. to iterate through all movies in a directory without
crafting a playlist. Eero said it needed to wait a bit before exiting; I
added a sleep() and made a Debian package.

Author: Tuomas Kulve
Source: https://bugs.maemo.org/attachment.cgi?id=687
Binary:
http://andrew.triumf.ca/N810/repository/dists/chinook/user/binary-armel/mime-open.deb

I'm still stuck trying to pass a file to a hildonized application. I
looked on the maemo tutorial and found how to update the MIME registry,
and built maemopad, so I can select a file with type foo/bar in the file
manager and have maemopad start. But like mplayer it won't open the file.
I guess it doesn't have the hooks. I was previously able to hook foo/bar
to "notes" in /etc/gnome/defaults.list
and download a foo/bar file in the browser - that worked OK.
Do you happen to know of an example using this launch hook ? I had hoped
that maemopad would have it.

--
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376 (Pacific Time)
Network Security Manager
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

advax at triumf

Jun 24, 2008, 3:33 PM

Post #12 of 13 (1035 views)
Permalink

RE: passing arguments to hildon applications [In reply to]

On Sun, 22 Jun 2008, Andrew Daviel wrote:

> Do you happen to know of an example using this launch hook ? I had hoped
> that maemopad would have it.

I found the source for PDFviewer (uses Xpdf I see..) on timeless.justdave.net
But it won't compile for me in Scrachbox (missing comapp).
Anyhow, I figure I *ought* to be able to find the relevant DBUS sections
in there to respond to hildon_mime_open_file. A hint from someone that
knows would be nice, though.

I.e. how to hildonize some app so it will work from the file manager or
the browser, or make a wrapper that accepts a DBUS request to open a
URL/file and does e.g. system("mplayer blah.wmv").

--
Andrew Daviel, TRIUMF, Canada
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

advax at triumf

Jul 21, 2008, 1:40 AM

Post #13 of 13 (781 views)
Permalink

RE: passing arguments to hildon applications [In reply to]

On Tue, 24 Jun 2008, Andrew Daviel wrote:

> I.e. how to hildonize some app so it will work from the file manager or
> the browser, or make a wrapper that accepts a DBUS request to open a
> URL/file and does e.g. system("mplayer blah.wmv").

Someone told me about dbus-switchboard which does what I want:
http://wardenclyffetower.com/MaemoFiles/utils/dbus-switchboard-1.2.0.all.deb
http://www.internettablettalk.com/forums/showthread.php?p=173560

But now I have a problem which seems a bit like the authentication
problem you mentioned.

If I place a WAV file on a server e.g. http://example.com/foo/bar.wav,
and click a link to it in the browser, and click "open with
media-player", the browser does a GET with Range: 0- and gets a partial
result. This appears to be discarded and gnome-vfs then does a full GET
on the URL and the sound plays.

But if I try to play a message from my voicemail system, gnome-vfs gets
the wrong URL and media player says "media stream not found at given
address"

GET /mycallpilot/open.asp?f_MsgNum=10&f_Format=WAV HTTP/1.1
User-Agent: Mozilla/5.0 (X11; U; Linux armv6l; en-GB; rv:1.9a6pre)
Gecko/20080606 Firefox/3.0a1 Tablet browser 0.3.7
RX-34+RX-44+RX-48_DIABLO_4.2008.23-14
..
HTTP/1.1 200 OK
Date: Mon, 21 Jul 2008 07:13:57 GMT
Server: Microsoft-IIS/4.0
Content-Disposition: attachment; filename=message.wav
Content-Length: 443438
Content-Type: audio/wav

then

GET /mycallpilot/message.wav HTTP/1.1
User-Agent: gnome-vfs/2.16.3 neon/0.25.4
TE: trailers
icy-metadata:1

HTTP/1.1 404 Object Not Found

Perhaps it is confused by the Content-Disposition header

--
Andrew Daviel, TRIUMF, Canada
_______________________________________________
maemo-developers mailing list
maemo-developers[at]maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com