Notices

I thought the dpad scrolling issue was a webkit issue. I suppose that doesn't entirely preclude their being related... Anyway, I was hoping that at least the dpad issue would be fixed in Mer before long. I believe it's FiF (Diablo has a library size limit or something, so we're stuck I think).

If you're looking for ideas, I don't think you need to support other browsers like Fennec or Midori initially, although long-term that might be nice. But creating a simple GUI for the key script settings would be a big boost in user-friendliness.

Tso mentioned including this in Pipeline's dbus-switchboard. That program allows you to change file associations, like what program is invoked when an HTML file is opened. But that's not quite what this script does, right? It's more a switchboard just for the Web panel specifically, right? IIUC and if you buy my logic, it could be called Web-switchboard.

That's the best suggestion I've heard so far -- describes in a nutshell what the script does. Wonder if web-switchboard or browser-switchboard is better?

Anyone have a better name idea?

More proposed patches for xiojason's browser-proxy script. All of these apply against version 2.0.

• 01-reorganize-browser-launching-code.patch: Move the browser launching code into its own class, to simplify the rest of the changes. Introduce a config option default_browser to select the default browser; takes values "tear" or "microb".
• 02-add-arbitrary-browser-support.patch: Adds support for launching an arbitrary program as the default browser. Set default_browser to "other" and other_browser_cmd to the command line of the browser you want to use, with '%s' as a URL placeholder (e.g. "fennec '%s'").
• 03-add-explicit-fennec-and-midori-support.patch: Adds explicit support for Fennec (tested, but with a highly nonstandard Fennec install) and Midori (untested) as the default browser. Set default_browser to "fennec" or "midori" to use. (With this patch, this script really isn't Tear-specific anymore . . .)
• 04-add-config-file-support.patch: Add support for loading configuration from a config file, $HOME/.config/browser-proxy. If a config file isn't found, the script will use the built-in defaults (continuous mode off, Tear the default browser). You can, for example, enable continuous mode and make Midori the default browser by doing this in a shell:
  
  Code:

  $ cat > /home/user/.config/browser-proxy <<EOF
  # This is a comment
  continuous_mode = 1
  default_browser = "midori"
  EOF

  If running in continuous mode, you can force the script to reread its configuration by sending it SIGHUP (kill -HUP pid).

(edit: add missing "EOF" in here document)

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?

hello,

this is very long thread, but can somebody say, will there be new version of tear available?

current version is very good, it is my primary browser on my n800. however, there are some problems and i would expect new version of webkit&javascript engine, if possible, to make tear even better browser.

as for problems, i find these most annoying:
* when i try to drag page and i hit link, tear recognizes this as click (it should not)
* when i tap and hold while draging, if i pause while draging, tear recognizes this as long tap and opens context menu.
* long tap on scrollbar opens context menu

There should be a new version of Tear for Diablo, I expect to release it in a month.

Please don't forget to make it connect to the network when loading the homepage at launch :-)

And please make it remember passwords on the pages it doesnt...and log into usa today lol

is their a feature in tear that makes tea
automatically