[FOSS-GPS] Whats up with FoxtrotGPS?

[Joshua Judson Rosen]

Timo Jyrinki <timo.jyrinki at gmail.com> writes:
>
> 2010/7/13 John Stowers <john.stowers.lists at gmail.com>:
> >
> > Just wondering what the plan is. I noticed BZR has not been touched in a
> > while, and there is still the ogm-widget branch waiting for
> > review/merging.
> 
> Well July is at least around here largely vacations and people might
> be just enjoying the sun with the first FoxtrotGPS release showing
> the way ;)

Something like that :)

Things seem to have got awefully busy where I am just as July rolled in--
summer went into full swing this month, here, and there are children,
gardens, schedule-changes, holidays, and even a bunch of birthdays and
things like that to deal with. My spare time has ended up being fairly
limited this month--on the order of a couple of hours per week. I keep
postponing this response hoping that I'd have a bigger single block
in which to collect my thoughts and write it; I guess I've also sort-of
been hoping that maybe I'd even find time to do something spectacular
(like finishing integration of Sander's changes) and turn this post into
a cheery milestone-announcement.

So, here's accumulated status-updates from the past ~month...:

I've been working at integrating that ogm-widget branch; it's progressing,
though slowly. I've uploaded the parts that I believe are solid progress
to my web-site, for the time being:

    http://www.hackerposse.com/~rozzin/foxtrotgps/branches/ogm-widget

If you notice that the timestamps in that branch are all remarkably
recent, it's because I'm actually doing this in multiple passes--
I have another branch here where I just ran through and merged stuff
selectively but atomically, to see how straightforward it was to
split the `use osm-gps-map' changeset from the other changes;
but that proved to be fairly confusing, so I'm going through
and splitting commits into smaller, more cohesive chunks that
are easier for me to understand (and I had a couple of false
starts, where I split a commit incorrectly).


I've also been picking over diffs from the last tangoGPS release that
Marcus posted: there's really not that much change there, but the
*breadth* of scope is still enough that there are some things that
we probably want, some changes that don't do anything but we could
integrate without problem, some changes that we can't apply because
they are to subsystems that no longer exist in FoxtrotGPS (like fixes
to the old, hand-crafted gpsd protocol-handler), and some changes that
we probably *don't want*.

In that last category, Marcus has introduced a (small) new API
for `data upload', which turns out to be used only by another
new bunch of code that uploads the current track to Marcus' server
under the feature-name of "live logging". As far as I can tell,
there's still no user-beneficial feature supported by that upload,
so I'm at a complete loss trying to understand why a user would
actually want to do that. Any ideas?

I've put together a summary of all of the changes between tangoGPS
0.99.3 (our base) and 0.99.4 and attached it at the end of this
message. It's basically sorted topologically, with things that
are easy/desirable to integrate at the top, followed by things
that depend on them, and then things that just can't be integrated
at the bottom.


> Works great by the way.

I figured that must be the reason for the silence... :)

> That said, not sure if that specific branch still needs some work,
> looking at the earlier discussion, or what are the general thoughts
> on that.

There are still some nits to work out, but mainly the merger is
just blocking on me as I pick through it.

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."

-------------- next part --------------
main.c:
* Call g_thread_init() if necessary (if gthreads not yet initialised).
* Don't bother calling gdk_threads_enter()/gdk_threads_leave().

Bounds-checking:
* src/tracks.c (track_log).

Changed what versions are reported to the tangogps.org server:
* src/friends.c

Whitespace changes:
* gps_functions.c
* friends.c

GUI spacing/etc. changes:
* interface.c
* gps_functions.c (set_label)

Enable un-loading/resetting loaded tracks:
* tracks.c, src/tracks.h: new fn, reset_loaded_track() [crude...?];
  show button79 (track "Reset") when loaded a track.
* callbacks.c: flesh-out on_button79_clicked().

Zephyr HxM heart-rate monitor support.
+ hrm_functions.c.
* interface.c: Added checkbutton18.
* configure.in: depend on bluez.
* calbacks.c: on_checkbutton18_toggled(),
              on_entry33_changed(),
              call osd_hrm() in on_darwingarea1_expose_event().
* gps_functions.c (cb_gps_timer): call get_hrm_data(), etc.
* src/tracks.c (track_log): write HR into trackfiles.
  Eek! Does this precludes using GPX as our primary format?

configure.in: Depend on libsoup-2.4.
* To be used for `live logging' and track-upload.

Track-upload (WTF is this for?):
* src/tracks.c: new fn, get_loaded_track().
+ src/dataupload.c, src/dataupload.h.
* src/callbacks.c: call data_upload() in on_button78_clicked()
  (the button is still hidden...).

`Live Logging' (WTF is this for?):
+ livetracks.c, livetracks.h.
* src/gps_functions.c (cb_gps_timer): call live_log().
* src/interface.c: Renamed "Enable Live Tracking" checkbutton to
  "Enable Live Logging", and show/use it.

New/updated/regenerated translations
(dependant on changes from src/friends.c, src/interface.c):
* po/Makefile
* po/Makefile.in
* po/POTFILES
+ po/hr.po
+ po/it.po
+ po/pl.po

Bugfixes in GPSD protocol-handler:
* src/gps_functions.c: assign lon to lon_deg rather than lat_deg....

Pseudo-support for new gpsd query-protocol.
* src/gps_functions.c.

main.c:
* A proper option-parser using GOption, like in FoxtrotGPS.
* New options:
  + "--flightmode" (unused--what is this???)
  + "--livelog" (enables `live logging' [as per above])
  + "--verbose" (unused; will presumably be used to control debug output?)