On Wednesday 19 May 2010 09:39:52 John Stowers wrote:
> > Since one of the things that we had been discussing for FoxtrotGPS was
> > providing different (more intelligent) autocentre modes, and
> > osm-gps-map does provide something for autocenter, it'd be nice if we
> > could make use of your autocenter feature somehow; but you have only a
> > boolean `do it or don't' option right now. Would you be open to
> > expanding that a little?
>
> Yes, I guess there are a few ways this could be done without too much pain.
> * add an autocenter-mode property and switch-case on that inside the lib
> * do the existing autozoom calculation in an internal signal handler
> that derived classes could intercept/connect before (and hence add
> their own autozoom behaviour)
> * expose the autozoom as a vfunc that derived types could override
> * mystery option 4
See my previous mail. A sane default implementation is enough, other modes can
be
implemented in the app quite easily by using set_mapcenter.
> > The map-repository properties are usable, but seem awkward: several
> > properties that would seem to be more appropriate on an `OsmGpsMapSource'
> > class ("repo-uri", "tile-cache", "image-format") are instead on the
> > OsmGpsMap class, which means managing all of these properties individually
> > in order to support custom map-repositories like we currently do in
> > FoxtrotGPS. I may just be allocating rope to hang myself here, but would
> > you be open to expanding the API to include a GObject type for map-sources?
>
> Perhaps, although the GObject per map source seems a little complex
> considering almost all the code in the different sources will be
> identical. Is there an intermediate option perhaps?
>
> * add OsmGpsMapSource and OsmGpsMapSourceSlippy
> * add map-source-object property
> * by default map-source-object gets assigned a OsmGpsMapSourceSlippy
> object with the values pulled from the current MapSource_t machinery
Slippy? Isn't that a view mode? IMO has nothing to do with map sources.
Anyway, I think I can set both foxtrotgps and internal map sources with the
current osm-
gps-map without too much hassle, so if you really want to change this, please
wait until
osm-gps-map integration is done.
> Yes, a patch for this would be great. It would also be worthwhile to
> rename the functions to osm_gps_map_poi_{add,remove} to match the work
> going on in the tracks-rework / gtk-3.0 branch.
Please no, keep it generic! I think the _image interface is more then enough
(once it uses
opaque pointers) to handle POIs and anything else that might be rendered this
way. So
don't make it POI specific please!
John, I also found another bug in osm-gps-map:
- map scale indicator is incorrect. It is location/center-map specific and
changes with
the latitude.
And on the wishlist:
- I would like to have a zoom-changed signal, so I can update the zoom slider
when zooming
in and out with the keybindings or mouse-scrollwheel.
- tangogps zoomed in and out on the mouse cursor when using the scrollwheel.
I'd love to
see that also working with osm-gps-map.
Updates in my branch:
- osm-gps-map mapsources now integrated.
- track loading and display works, if loaded from file.
- all keybindings restored (and slightly changed, removed need for modifier
keys)
- friends now shown on map
Still to do:
- show POIs and Photos, once the _image functions are usable (and refactor
friends then
too)
- support foxtrotgps map sources, boilerplate already there, need only to set
the correct
properties
- draw line when in distance mode (using _track functions probably)
- cleanup code, remove all unused paint code
- merge to trunk ;-)
grtz,
Sander
_______________________________________________
This message is sent to you from [email protected] mailing list.
Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
subscription
For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
