FoxtrotGPS: Difference between revisions
Brian Wilson (talk | contribs) |
Brian Wilson (talk | contribs) |
||
Line 119: | Line 119: | ||
=== Contributing changes === | === Contributing changes === | ||
# Log in (you only have to do this once on a computer) | |||
# Create a branch | # Create a branch | ||
# | # Edit files, fix your bug or add your change | ||
# Commit the files that changed | # Commit the files that changed (which only affects your computer) | ||
# | # Send the changes to the maintainer, there are several ways to do this. | ||
# Update your source code | # The maintainer(s) will evaluate your change and if they are acceptable, merge them into the trunk in a timely fashion. | ||
# Update your source code from the trunk | |||
''' | '''Logging in''' bzr whoami "Brian Wilson <brian@wildsong.biz>" | ||
bzr branch http://www.foxtrotgps.org/branches/foxtrotgps-dev/ | '''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. | '''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 it goes without saying, compile and test before sending changes in.) | |||
'''Commit your change''' bzr commit -m "These changes fix bug number 663102" | |||
If your change is taking awhile (you are adding a feature) you might decide to do more commits before actually sending changes to the maintainer. | |||
'''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/ | |||
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. |
Revision as of 02:48, 25 October 2010
Notes on FoxtrotGPS, the usual Wildsong page -- I write until I have a basic understanding, then leave you hanging.
User guide
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
Prequisites
Taken straight from the source
- pkg-config <http://pkg-config.freedesktop.org/>
- GLib 2.x <http://www.gtk.org/>
- GTK+ 2.x <http://www.gtk.org/>
- libglade 2.x <http://ftp.acc.umu.se/pub/GNOME/sources/libglade/2.6/>
- GConf 2.x <http://www.gnome.org/projects/gconf/>
- libcurl <http://curl.haxx.se/>
- SQLite 3 <http://www.sqlite.org/>
- libexif <http://libexif.sourceforge.net/>
- libxml2 <http://xmlsoft.org/>
- libgps >= 2.90 <http://gpsd.berlios.de/>
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
- Log in (you only have to do this once on a computer)
- Create a branch
- Edit files, fix your bug or add your change
- Commit the files that changed (which only affects your computer)
- Send the changes to the maintainer, there are several ways to do this.
- The maintainer(s) will evaluate your change and if they are acceptable, merge them into the trunk in a timely fashion.
- Update your source code from the trunk
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 it goes without saying, compile and test before sending changes in.)
Commit your change bzr commit -m "These changes fix bug number 663102" If your change is taking awhile (you are adding a feature) you might decide to do more commits before actually sending changes to the maintainer.
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/
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.