FoxtrotGPS: Difference between revisions

From Wildsong
Jump to navigationJump to search
Brian Wilson (talk | contribs)
Brian Wilson (talk | contribs)
Line 79: Line 79:


== Building on Ubuntu 10.04 ==
== Building on Ubuntu 10.04 ==
Actually this works on my Debian 5.0 machine, too.


=== Prequisites ===
=== Prequisites ===

Revision as of 02:58, 25 October 2010

Notes on FoxtrotGPS, the usual Wildsong page -- I write until I have a basic understanding, then leave you hanging.

User guide

File:Foxtrot screenshot.png

Sidebar

there are 7 buttons on the left sidebar

Show info - toggle a panel on the right side on/off

Fullscreen

Zoom in

Zoom out

Autocenter - Keeps the map centered on the current GPS position.

Next - Selects the next map source - the list of map sources is set in the Configuration panel

Prev - Selects the previous map source

Map

Context menu

this point

show friends

show POIs

show photos

ways & routes >

POIS >

photos >

my position >

map download

map detail >

Right panel

Toggled on/off with the i button.

Arrows at top rotate through 4 panels:

1 Trip Meter

2 Friends

3 Tracks

4 Configuration

Friends

Looks like you can register at a central web server, and send updates on your position at a selectable interval (default 5 minutes). You can set a status ("What are you doing")

Peeking at the code, it looks like it's using "curl" to send messsges to a Web server.

The projects list at FoxtrotGps.org suggests that standards would be better and that a couple possibilities are XMPP (Jabber) and YouLoc.net

I am looking at GeoRSS and wondering if it's applicable. GeoRSS supports drawing shapes (not just points) on a map, so for example the extent of a flood could be transmitted as a polygon.

I am also wondering how to fit APRS into the picture. I'd like to have APRS stations appear on my FoxtrotGPS map.

The bits and bobs

FoxtrotGPS builds on a rich foundation of open source components.

Building on Ubuntu 10.04

Actually this works on my Debian 5.0 machine, too.

Prequisites

Taken straight from the source

What I had to install

Starting with a machine that's been used to compile and build projects, I still had to install some stuff.

I downloaded and built curl and gpsd from source, Ubuntu version is outdated.

sudo apt-get install libgconf2-dev libglade2-dev curl sqlite3 libsqlite3-dev \
  libxml2-dev libexif-dev libcurl3
sudo apt-get install bzr
sudo apt-get install autoconf intltool libtool

bzr branch  http://www.foxtrotgps.org/branches/foxtrotgps-dev/
cd foxtrotgps-dev/
./autogen.sh
./configure
make
sudo make install
foxtrotgps

It runs!

Contributing changes

Overview of the steps:

  1. Log in (you only have to do this once on a computer)
  2. Create a branch
  3. Edit files, fix your bug or add your change
  4. Commit the files that changed (which only affects your computer)
  5. Send the changes to the maintainer, there are several ways to do this.
  6. The maintainer(s) will evaluate your change and if they are acceptable, merge them into the trunk in a timely fashion.
  7. Update your source code from the trunk

More details:

Logging in bzr whoami "Brian Wilson <[email protected]>"

Creating a branch is almost the same as the first step to building from source. You should check out code to your own branch, for example I am working fixing bug 663102, so I do it like this. This makes it easier to tell your branch from the trunk when you submit patches.

bzr branch  http://www.foxtrotgps.org/branches/foxtrotgps-dev/ foxtrotgps-663102

If you are working on a new feature instead of a simple bug fix you might name the branch after the feature, for example "foxtrotgps-usng-support".

Make your change or addition or whatever. "One change" means you want to do the minimum necessary to, for example, fix just one bug, not several bugs. This makes evaluating the work you did easier for the maintainers, and therefore decreases the turn around time on your changes being incorporated (and increasing the probability that the changes will be accepted!)

(And it goes without saying, compile and test thoroughly before sending changes in.)

Commit your change bzr commit -m "These changes fix bug number 663102" The bazaar model is to keep the code on your machine until you publish the changes. So you can do many commits until you are ready to share the changes. This makes sense if you are adding a new feature and want the benefits of version control without having to publish non-working code.

Send the changes the maintainer. If the change is relatively small, you can "send" the changes to a patch file and then attach the file to the bug in the comments section of the bug tracking system.

The bug tracker is here: https://bugs.launchpad.net/foxtrotgps/

The send-to-a-file command looks like this.

~/src/foxtrotgps-663102$ bzr send -o ../fix663102.patch

Now you can use a web browser to connect to the bug tracker, add a comment to 663102, attaching the file fix663102.patch.

If you are working on a big change and you have access to your own publicly accessibly SFTP site, you can set up SFTP access, upload your changes to your site, and then tell people the URL either by email or in the bug tracker.

Now you have to wait for the changes to be accepted, and merged into the trunk.

To work on a NEW bug or feature, you'd start the whole cycle again, checking out a new copy of the code so that you are starting from the trunk.

Setting up an SFTP site is really beyond the scope of this little doc, if you want to commit changes and this is beyond you, I am sympathetic! We want your help, and we will make other arrangements.