Fremantle: Coexist with a running MicroB process; don't kill MicroB at end of session if MicroB is the default browser

With commit 07a0e091... ("Tweak detection of com.nokia.osso_browser
acquisition slightly"), it's almost possible to support opening a new
window in an already-running MicroB.  All we have to do is avoid
invoking a new browser process in that case, so do that here.

It also turns out to be possible to take back the com.nokia.osso_browser
D-Bus name from MicroB without killing it, which is interesting to us
because the need to kill MicroB is what necessitates the behavior
changes we force on MicroB.

On the other hand, if we choose to avoid killing MicroB, we lose the
ability to have MicroB take over handling osso_browser requests while a
MicroB window is open, and we waste memory for users who aren't using
MicroB very often.

Therefore, we take a compromise approach: if MicroB is set as the
default browser, we don't bother killing MicroB when the last browser
window closes (which simplifies the code considerably, since we no
longer need to monitor MicroB while it's running, and also means that
MicroB should behave as it does when browser-switchboard isn't running).
Otherwise, we act as before (watch the running MicroB and kill it when the
last browser window closes, with the behavior changes this requires).

For control freaks, there's also a new autostart_microb config option
which allows you to override this heuristic.  Setting autostart_microb
to 0 forces us to kill MicroB even when MicroB is the configured default
browser, and setting it to 1 forces us to leave MicroB running even when
MicroB isn't the default.

Refactor Fremantle launch_microb code

Split out code that will be shared with the new code to launch a window
in an already-existing MicroB process to separate functions, and move
the rest of the existing hairball into a new
launch_microb_fremantle_with_kill() to make it easier to plug the
forthcoming launch_microb_fremantle() in.

Tweak detection of com.nokia.osso_browser acquisition slightly

Instead of looking for an empty old owner string, look for a nonempty
new owner string -- this picks up cases where ownership changes hands as
well as cases where a previously unowned name is acquired.

Add command-line utility to Makefile install target

Restore webpages

This reverts commit 8cb71fe8a77dc9a723232c815ee4457da3fb4103.

Remove webpages for release

Config UI: leave other_browser_cmd unset instead of configuring an empty value

It used to be that when the user cleared the value of other_browser_cmd
in the UI, the setting would be removed from the config file instead of
writing an empty value.  Restore this behavior.

Fix check for whether a browser is installed

The intent was to exempt MicroB (and any other browser listed with
browser->binary = NULL) from the check, but the tests here didn't do
that.  Fix this so that default_browser = microb doesn't emit a warning.

Command-line utility: avoid NULL dereference when displaying string config settings

Update README and Changelog

Fix memory leak on reconfiguration

Caught by valgrind.

Describe MicroB slightly more verbosely in the UI

Emanuele Cassioli pointed out that users could potentially be unfamiliar
with the name "MicroB", since it's not used in normally user-visible
places.  Rename the entry "MicroB (stock browser)" to hopefully help
these users; better suggestions welcome.

Don't use a browser as the default browser if it's not installed

Add locations for the known browsers' binaries, and check to see if the
binary is installed before using a browser as the default.

Get rid of boilerplate code in swb_config_free()

We can loop over swb_config_options[] instead of identifying every
string config option explicitly here.

Avoid structure copies when looping through swb_config_options

Remove use_other_browser_cmd()

use_other_browser_cmd() is only called from one place now, so just move
its code there and get rid of the function.

Use an array of browser launchers instead of boilerplate code in update_default_browser()

Replace the existing set of if-elses comparing default_browser against
string constants with a loop over an array of browser launchers, which
will be (marginally) easier to maintain.

Update webpage

Introduce command-line config utility

Add a simple command-line configuration utility,
browser-switchboard-config, which can be used to query or set
browser-switchboard config settings.

The primary purpose of this tool is to allow browser vendors to provide
an option in their browsers to set themselves as the default browser,
via something like this (shell-like pseudocode):
if [ -x /usr/bin/browser-switchboard-config ]; then
if [ `browser-switchboard-config -b` = "mybrowser" ]; then
display "MyBrowser is the default browser."
else
button "Make MyBrowser the default browser" action "browser-switchboard-config -s -b mybrowser"
fi
else
display "Install Browser Switchboard to make MyBrowser the default browser"
fi
Browser vendors: setting yourself as the default browser without
prompting the user first (via package maintainer scripts, for example)
is strongly discouraged.

Indentation fixes

Clean up configuration again

Commit ec8b58af... ("Refactor configuration") still has too much
boilerplate code and leaves too many places that have to be modified to
add a new config option.

To fix this, add a new array of config options with name and type of
information stored, and then add an array of pointers to the elements of
struct swb_config with indices matching the list of config options to
struct swb_config.  This consolidates all the work needed to add new
config options to config.h and config.c, and allows us to replace the
boilerplate code with loops over the array of config options.

Refactor configuration

Most of the code for loading configuration from the config file was
being duplicated between the UI and the main browser-switchboard code;
also, the forthcoming command-line configuration tool should share the
code for loading and saving configuration with the UI.  Therefore,
move code for loading and saving configuration information into
functions generic enough to be shared between the UIs and
browser-switchboard.

Add preliminary support for Opera Mobile

We do this the lazy way, using use_other_browser_cmd("opera %s").  The
Opera Labs post announcing Opera Mobile for Maemo
(http://labs.opera.com/news/2010/05/11/) says that "an extra empty tab
will get opened every time you open a link from an external
application", so I suspect we may need a different method of opening
links in an already open browser.

Whitespace cleanups

Avoid use of Fremantle codename alone, for clarity

Update webpage

Note that on Fremantle, MicroB browser windows should be closed before installing

Restore webpages

This reverts commit 4426a6e201e88459830f194617af1d5dd14ed3ef.

Remove webpages for release

Update Changelog

Update README

Revert "Make startup notification work for MicroB menu entry"

This behaves very badly if you try to use the MicroB menu entry while
MicroB is already open (a new MicroB will open after you close the
MicroB).

This reverts commit 846e68b8ffa979d30ed331c43020212ffdee2bf2.

Make startup notification work for MicroB menu entry

To have working startup notification, we have to provide a D-Bus service
with a top_application method; hildon-desktop will then use that to
launch the application instead of invoking the binary directly.  Co-opt
the org.maemo.garage.browser_switchboard name previously used for
locking for this (replacing a - with a _ to get around D-Bus naming
restrictions).

While we're at it, remove the non-standard switchboard_launch_microb
method from the com.nokia.osso_browser interface we implement, instead
providing a launch_microb method in our own interface.

Link binaries with -Wl,--as-needed to reduce library dependencies

Using pkg-config --libs to get library link lines has the disadvantage
of bringing in many more library dependencies than actually necessary,
since that assumes that dependencies of libraries need to be specified
explicitly at link time (even when the library is itself linked against
those dependencies).  Using GNU ld's --as-needed option causes these
unnecessary dependencies to be omitted from the binary.

--as-needed needs to be specified after all the objects to be linked
into the binary and before the libraries, so some reordering of the link
command line is needed.

Fix Makefile install targets

The overhaul of the Makefile targets broke the dependencies of the
install targets; fix this (along with a broken strip target in
config-ui/Makefile).

Fix Makefile clean targets

Since we have a list of objects that we build already, use that in the
clean targets instead of *.o.  This fixes the config-ui Makefile clean
target, which was potentially missing ../configfile.plugin.o.

Update build system

As currently set up, it takes far too much external knowledge to
generate builds for Fremantle (a set of EXTRA_CPPFLAGS as well as
EXTRA_LDFLAGS); this is because the Makefiles were originally written
when there was only one target system (Diablo).

To fix this, provide new "diablo" and "fremantle" targets that can be
used to build the appropriate browser-switchboard without further
configuration, and make the "all" target print out a help message.  For
the config UI, provide new "fremantle-hildon-app" and "fremantle-plugin"
targets, and rename the existing targets to "diablo-hildon-app" and
"diablo-plugin" to match.

Make "Web" menu entry and /usr/bin/browser open the default browser

Currently, no matter what the default browser is set to, the "Web" menu
entry opens MicroB, and running /usr/bin/browser does the same. This is
done to make sure that there's always a way of opening MicroB regardless
of the default browser setting.

However, this behavior would seem to be less than intuitive (why does
the entry marked "Web" not open the default browser? on Diablo, why do
the Web sidebar panel and Web menu entry do completely different
things?).  Therefore, do the following:

* Make the top_application method in the D-Bus interface open the
  default browser, not MicroB, and therefore make the "Web" menu entry
  open the default browser.
* Ship a new microb.desktop file which provides a MicroB menu entry that
  launches MicroB.
* Rename the existing /usr/bin/browser script to /usr/bin/microb.
* Ship a new /usr/bin/browser script which launches the default browser.

This has one primary disadvantage: none of the standard methods of
launching a browser on Maemo can be guaranteed to bring up MicroB (with
the old behavior, invoking /usr/bin/browser was guaranteed to bring up
MicroB, just as if Browser Switchboard weren't installed).

Make config printout go to selected log target

The config printout that gets displayed on startup was happening before
log_config(), so it was always going to stdout regardless of the logging
setting.  Fix this.

Add a new config setting for logging

Add a new config setting:
logging = "stdout" -- log to stdout (default)
logging = "syslog" -- log to syslog
logging = "none" -- disable logging
No configuration UI is exposed, but the UI needs to be taught that this
is a legal config setting (so that it doesn't discard it).

Convert existing code to use the new logging infrastructure

Add logging functions with selectable log output targets

Currently, our "logging" consists of a mix of printf(), perror(), and
other such calls which print output to stdout/stderr.  In normal usage,
browser-switchboard will be launched by D-Bus, which results in
stdout/stderr pointing to /dev/null and debugging output being lost.

To improve this situation, introduce a new set of logging functions
log_out() and log_perror(), and a log_config() which allows choosing the
log target.  These functions log to stdout by default, but also support
syslog output (to the LOG_USER facility, with priority LOG_DEBUG) and
disabling logging entirely.

Thanks to Faheem Pervez (qwerty12) for the suggestion.

Force the Fremantle Ovi Store bookmark to open in MicroB

The Ovi Store apparently only comes up if you visit with MicroB, so
force the link in the Ovi Store bookmark to open in MicroB.

Reported by maemo.org talk user ToJa92; additional details provided by
Faheem Pervez (qwerty12).

Update copyright year

Clarify control flow in inotify read loop

Replace pointer arithmetic that makes the loop condition false with a
simple break; functionally equivalent, but much clearer.

Ensure that only one browser-switchboard is active at any time

When launching MicroB, during the window between the time we let go of
com.nokia.osso_browser and the time MicroB picks it up, it's possible
that some process issues a request for the interface, which causes D-Bus
to attempt to start another copy of browser-switchboard; the results are
confusing at best and (in the Fremantle case) disastrous at worst.
Prevent this by trying to acquire the name
org.maemo.garage.browser-switchboard from D-Bus on startup, in a manner
that succeeds if and only if no one else already owns the name.

This is important because the Fremantle hildon-desktop appears to
sometimes insist on having a process to own com.nokia.osso_browser at
all times; when it decides this is necessary, it picks up our release of
the name and immediately asks D-Bus to launch another
browser-switchboard, which gets in the way of our MicroB launching
procedure.

Avoid a race between MicroB startup and establishing D-Bus watch for it

As it stands, the establishment of the D-Bus match and filter for the
acquisition of com.nokia.osso_browser happens in parallel with MicroB
startup; as a result, it's possible that MicroB could acquire the name
before we're ready to look for the event, which results in us waiting
forever for MicroB to start (even though it's already started).  Avoid
this by establishing the watch before we fork a child process.

Possibly fixes a rare failure mode reported by Faheem Pervez (qwerty12).

Install the inotify watch for lockfile creation before forking

This avoids the silliness of doing this in both the parent and child
process.

Take a different approach to detecting MicroB browser window close

As it turns out, the Fremantle IM/SMS application also spawns a
browserd; this browserd also attempts to claim the Mozilla.MicroB or
com.nokia.microb-engine D-Bus name, which means that we cannot count on
the MicroB browserd actually having ownership of this name.

Assuming that this D-Bus name is actually needed by anything else, this
is broken by design (since only one connection can own a name on the bus
at any time, and which browserd owns the name appears to be
nondeterministic); of course, I haven't observed any actual use of this
name in my testing either.  Who comes up with this stuff?!?!!?!

In any event, take a different approach to detecting when the MicroB
browserd closes: get the browserd PID from its profile lockfile, then
ptrace() the process to learn when it closes.  There are various
complications which make this more involved than we'd like, but this
should be a foolproof method of detecting the browserd close.

Update webpage

Avoid two consecutive parens in webpage text

Update Fremantle screenshot with new 3.1 UI

Update webpage

Kill MicroB browser UI processes instead of using exit_browser

Reports from users suggest that the exit_browser method call currently
being used to close the MicroB browser UI processes may not be working
reliably.  Try a kill() instead, and hope that this doesn't introduce
data loss problems ...

Make sure a running browserd is detected correctly on all devices

`pidof /usr/sbin/browserd` doesn't work on at least one user's device;
`pidof browserd` works everywhere without exception, so use that
instead.

Reported by Faheem Pervez (qwerty12).

Update copyright year

Throw away stdout/stderr for browserds we launch too

Commit d8d8d1ed... ("Close stdin/stdout/stderr in child processes before
exec()") didn't prevent browserd from spewing noise, because we invoke
that via system() instead of fork()/exec().  Fix that oversight.

Fix some abuses of the D-Bus API

dbus_g_proxy_call() needs two G_TYPE_INVALIDs in the arguments, one to
terminate the list of input variables and one to terminate the list of
output variables.  This was causing an error, which we were ignoring;
now that we don't get an error every time, print the error message and
exit instead of continuing silently in the face of errors.

Also, make sure the dbus_g_proxy_new_for_name() call succeeds, instead
of potentially passing a NULL tear_proxy to dbus_g_proxy_call().

Close stdin/stdout/stderr in child processes before exec()

stdout/stderr output from the browser processes we exec() is noisy,
useless, and getting in the way of our debugging output.  Fix this by
throwing it away.

Zap one more extraneous #include from Fremantle MicroB work

Remove some unnecessary #includes that crept in

Initial support for launching MicroB on Fremantle

MicroB in Fremantle has been changed to accommodate keeping the UI in
the background full-time as well as the browser engine (browserd).  As a
result, running "browser" no longer shows a browser window, and the
browser process doesn't relinquish the com.nokia.osso_browser D-Bus name
and quit when the last browser window closes.

Instead, launch the browser by starting the UI process in the
background, waiting for it to acquire the com.nokia.osso_browser name,
then using the D-Bus API to open a window.

Detecting when the last browser window is closed is trickier.  The
method we use is to notice that when the last browser window closes,
the UI process closes and reopens the browserd renderer, causing a
change in the ownership of the Mozilla.MicroB D-Bus name (or
com.nokia.microb-engine in Maemo 5 PR1.1).  We detect this change and
send the UI process an exit_browser D-Bus method call, causing it to
quit and relinquish the com.nokia.osso_browser name back to us.

Unfortunately, this method cannot detect when the bookmarks window is
closed.  This means two unpleasant surprises, both needed to make sure
that the bookmarks window is never the only MicroB window open (in that
situation, if the user closes the bookmarks window without first opening
another normal browser window, we wouldn't be able to detect the window
closing and ensure we get the com.nokia.osso_browser name back):

(1) Our top_application method, which should behave exactly like opening
    MicroB from the menu normally does (bring up the bookmarks window),
    brings up about:blank instead.
(2) We kill off MicroB and reclaim the com.nokia.osso_browser name when
    the last normal browser window closes, regardless of whether the
    bookmarks window is open.

Ideas for better ways to detect when all MicroB windows have closed are
welcome.

Code for monitoring when a D-Bus name changes hands draws on ideas from
the dbus-monitor source (tools/dbus-monitor.c in the D-Bus
distribution).

Restore webpages

Remove webpages for release

Bump version number in README/Changelog

Spelling/grammar fixes to comments

Update Changelog

Add support for EXTRA_CPPFLAGS/EXTRA_LDFLAGS in Makefiles

Update copyright notices

Diablo: disable autocap/predictive text for the other_browser_cmd entry

The Fremantle UI introduced in commit 18bad5e9... ("Revise GUI for
Fremantle to be more finger-friendly") disables autocapitalization and
predictive text/dictionary features for the other_browser_cmd entry --
those input method features are for natural language text only, and get
in the way here.  Now do the same for the Diablo UI (and make a style
cleanup along the way).

Revise GUI for Fremantle to be more finger-friendly

Make the GUI for Fremantle more finger-friendly by making the widgets
larger and using HildonTouchSelector widgets in place of combo
box/radiobutton widgets.

Based on a patch by Faheem Pervez (qwerty12):
http://slexy.org/view/s2JL7ye01p

Ensure reconfig signal doesn't interrupt request dispatch when (!continuous_mode)

If SIGHUP is sent to a browser-switchboard process with continuous mode
off, the process will quit.  This is the right thing to do in most cases
(the next request will relaunch the process, at which point it'll read
the new config), but if we're in the middle of dispatching a request
when the signal arrives, quitting immediately will cause the request to
be lost.

Since browser-switchboard quits upon completion of a request when
continuous mode is off anyway, fix this by just ignoring SIGHUP while
handling requests when continuous mode is off.

Update webpage to recommend installation from extras

Add an .install file for installing from extras

Update current release section of webpage, link to new forum thread

Update webpage, add some screenshots

Readd webpage

Update README and Changelog

Remove webpage for release tarball

Update webpage

Support EXTRA_CFLAGS in Makefiles

This makes it possible to specify additional CFLAGS at build time.

Use pkg-config libosso instead of pkg-config dbus-1 for the plugin

The hildon-control-panel plugin interface needs libosso to compile;
the use of pkg-config dbus-1 was just covering this up.

Update webpage

Don't use killall to HUP browser-switchboard

Use kill and pidof instead -- killall might kill a standalone config app.

Fix dependencies listed in README

config-ui: Teach UI how to HUP C browser-switchboards

Readd the webpage

www got clobbered in the merge.

Add the version number to the README

Update Changelog and README

Default to launching MicroB if default_browser is unset

The check-for-Tear-and-use-MicroB-otherwise hack was only until we got a
config UI.  Now that we have one, it's easiest just to keep MicroB as
the default until the user configures browser-switchboard.

Make the default prefix /usr

We're already assuming this in several places, and it's too much work to
make those files autogenerated when no one's going to use that feature.

config-ui: the strip and install targets only work for the plugin

Ensure that all objects for the plugin are built with -fPIC

mkdir all the directories to which we install files, not just some of them

Merge branch 'config-ui' into c-implementation

Remove the N8x0-specific CFLAGS

These should move to packaging.

Remove the N8x0-specific CFLAGS

These should move to packaging.

HUP running browser-switchboard processes after saving config

Sending SIGHUP to a running browser-switchboard in continuous mode
causes it to reload its config.  If not in continuous mode, it'll die
and the next browser-switchboard will pick up the config changes.

Use a stock GTK+ dialog

Use the stock OK/Cancel GTK+ dialog instead of making our own.  Also
use the response from gtk_dialog_run() to decide whether to save instead
of using custom callbacks for the buttons.  Should make the dialog more
Maemo 5 friendly.

Also, eliminate some unnecessary crap in the hildon-control-panel plugin
path, and reintroduce do_reconfig() in preparation for adding HUPing of
a running browser-switchboard.

Don't execute hildon_program_get_instance() before gtk_init()

Shuts up some runtime assertions in the Hildon app.