Two more patches, which I'm not so sure about. These are to support a script replacing /usr/bin/browser.

/usr/bin/browser has two problems when used with browser-proxy:

• If /usr/bin/browser is invoked from the command line, the resulting MicroB won't handle the osso_browser D-Bus methods -- browser-proxy will instead. This is unlike what happens when MicroB is launched from the menus.
• If browserd is disabled, running /usr/bin/browser directly doesn't work at all (unless you start browserd yourself).

I'm thinking of having the attached script (browser-wrapper) replace /usr/bin/browser in the next version of my package. browser-wrapper uses D-Bus to launch MicroB, thus getting around both of the problems above. Unfortunately, it needs a couple of (what I consider) somewhat unpleasant changes to browser-proxy to work:

• 05-extend-top_application-with-uri-param.patch: Implements a new, "undocumented", nonstandard extension to the top_application D-Bus method to allow it to take an optional URI parameter. If a URI is given, the MicroB launched will load that page; otherwise it behaves as before (loads the home page). browser-wrapper needs this so that it can support loading a URL via a command-line option.
  This is nasty in that we're extending an API that doesn't really belong to us, but the "proper" alternative (adding a new D-Bus method in our own namespace) is more work for no real gain.
• 06-exec-maemo-invoker-instead-of-using-browser-symlink.patch: By default, /usr/bin/browser is a symlink to /usr/bin/maemo-invoker, which checks what name it was invoked under to decide how to behave. Obviously, if we're going to replace /usr/bin/browser with a script that might call us via D-Bus, we can't exec /usr/bin/browser without risking a loop.
  Instead, run maemo-invoker directly with argv0 set to browser, so that it thinks it was called as browser. This is identical to running a browser symlink pointing to maemo-invoker, but not exactly transparent.

Thing is, though, I'm not convinced browser-wrapper does the right thing in the first place. Should running /usr/bin/browser start MicroB specifically (what browser-wrapper does), or should it start the default browser (whatever browser-proxy is configured to use)? In the latter case, we don't need these patches at all, but having browser-wrapper do that means that we lose the ability to run MicroB from the command line in any way that also works on systems without browser-proxy.

Thoughts?