Update debian/changelog, bump version number

Add a postinst to kill off prestarted MicroB browser process

On Fremantle, a MicroB browser process is prestarted by default on
device startup.  This browser process takes com.nokia.osso_browser,
which means that link requests will not launch browser-switchboard
unless we kill off this browser process or restart the device.

Add a Fremantle-specific microb.desktop

MicroB's icon has a different name in Fremantle, so we need to modify
the .desktop file that we ship.

Build fremantle targets in debian/rules, clean up old unused cruft

Merge commit 'diablo-package-3.2-1' into test-branch

Conflicts:

debian/changelog
debian/rules

Revert "Initial support for launching MicroB on Fremantle"

This reverts commit f4665fd53d5c0e352e36326efee27e6ce6edce1d.

Revert "Remove some unnecessary #includes that crept in"

This reverts commit f6c9c1bcdb9a50cff459d69feeab1caa909f098c.

Revert "Zap one more extraneous #include from Fremantle MicroB work"

This reverts commit d39042804d1ee8b5f57dd5c1af884ea4e208b30a.

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

This reverts commit 17853b6cdd152a6c53a3e3e11506e3a780e4991c.

Revert "Throw away stdout/stderr for browserds we launch too"

This reverts commit 30d5e7a1400fb294e75e2199e3a4de5176e84506.

Revert "Make sure a running browserd is detected correctly on all devices"

This reverts commit aea8af77e9b8614776a3be05a4dff86ea25063f6.

Revert "Kill MicroB browser UI processes instead of using exit_browser"

This reverts commit 6f2522256b931713418b8d747612255c03481e21.

Revert "Take a different approach to detecting MicroB browser window close"

This reverts commit d1664d84713a1b9731e8c726cd0e69fe38eb5872.

Revert "Install the inotify watch for lockfile creation before forking"

This reverts commit c3c41ba1385b47dc2a167e963478779ad5c952fe.

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

This reverts commit 807b507a9f6cc3be8f12d68f7849da970652a9a6.

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

This reverts commit ae25c6b332df1c92b1433474bbf4c8b8b857b7ff.

Update debian/changelog, bump version number

Enable building with -mthumb for ARM by default

The Diablo autobuilder passes an invalid DEB_BUILD_OPTIONS (options
should be space-separated, not comma-separated), and the Fremantle
autobuilder doesn't pass "thumb" in DEB_BUILD_OPTIONS at all, so the
existing code was an effective no-op.  We know we want Thumb
instructions by default, so build with -mthumb by default and offer a
"nothumb" option to turn it off.

Update debian/rules for new build system

Merge commit 'v3.2' into test-branch

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 debian/changelog, bump version number

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.

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.

Update debian/changelog, bump version number

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.

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

Update debian/changelog, bump version number

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).

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 debian/changelog, bump version number

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.

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.

Revert "Drop the Depends on tablet-browser-ui for Diablo, for now"

This is a Diablo-specific change; the Fremantle package interface
doesn't suffer from this bug.

This reverts commit e294fa1e04cde59acaa7f07f7831cc7bfbd35b02.

Merge branch 'diablo-package' into fremantle-package

Update changelog, bump version number

Drop the Depends on tablet-browser-ui for Diablo, for now

tablet-browser-ui is in the Diablo rootfs image, which means that (1)
everyone has it and (2) the maemo.org packages interface doesn't know
that it exists.  Since the packages interface bug now prevents new
versions of browser-switchboard for Diablo from going to extras, work
around this for now by losing the dependency.

See https://bugs.maemo.org/show_bug.cgi?id=8806 for more information.

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.

Update changelog, bump version number

Build-Depend on libdbus-1-dev, use pkg-config for dbus-1

We now use the low-level D-Bus API in the Fremantle code, so we need to
depend on libdbus-1-dev and get the pkg-config information for dbus-1
for correctness.

Zap one more extraneous #include from Fremantle MicroB work

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).

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).

Update debian/changelog, bump version number for Fremantle

Merge branch 'diablo-package' into fremantle-package

Build Fremantle-specific code by passing -DFREMANTLE in EXTRA_CPPFLAGS

Merge commit 'v3.1' into fremantle-package

Update debian/changelog, bump version number

Merge commit 'v3.1' into diablo-package

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

Note Fremantle-specific packaging changes in debian/changelog

Update debian/changelog, bump version number for Fremantle build

Merge branch 'diablo-package' into fremantle-package

Update debian/changelog

Remove debian/dirs, not needed with new Makefile-based build