2010/5/19 John Stowers <[email protected]>: >> So, it looks like osm-gps-map would mostly be a pretty good fit to >> FoxtrotGPS. >> >> There are a few things that initially scared me but have turned out to >> be non-issues and a few minor nits for which I'm preparing some patches >> foryour review, > > Yeah, as I said on previous mail, they look good. I will apply them > when I get back at my development PC. > >> but also a couple of other items that are still bothering me >> and for which I don't have a solution on-hand. Critique and questions follow. >> >> I see that "automatically draws a GPS track" is something that can be >> toggled, so that's OK. That you have things like `tracks are drawn in red' >> hard-coded in osm_gps_map_print_track() makes the whole track-management >> API basically useless to me, so I'd want to do something about that. >> It's not necessarily a deal-breaker, though--we could presumably use your >> `layer' API to just do the track-rendering ourselves. > > I am currently cleaning up the track API at the moment (see my > previous reply to Sander) and the track-api-rework branch > (http://github.com/nzjrs/osm-gps-map/tree/track-api-rework). > > Your comments would be appreciated. > >> >> 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 > > What do you think of these approaches considering > * the implementation should be future proof to some degree, so that > new autozoom modes could be added > * existing users of the library will not be impacted too much > * the library retains a good default level of functionality > >> >> >> Looking deeper...: >> >> 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 > > While this could be almost a way draw an interface between tile > fetching and rendering, as far as your use is concerned it almost > seems as the worst of both worlds and the better of none. > > More thought and your comments would be appreciated on this. > >> >> As Sander pointed out, the high-level osm_gps_map_draw_gps() may be either >> too high-level or just not quite the right fit: at the very least, we need >> to be able to provide a second directional indicator that points to a >> destination; if Sander's concerns about slowness of the alpha-blended icon >> are correct, then we'd also want to find another way of indicating HDOP. >> I suppose we may want to be able to augment or change the icon in other >> ways in the future, but I don't have anything specific in mind right now. > > I have also had other people suggest that they wanted other ways to > draw the current GPS point/HDOP/etc. I think this definately qualifies > (i.e. patches welcome) as the kind of thing that would be suitable for > a vfunc (draw_gps_point) that derived classes could then override.
draw_gps_point has now been made a virtual function that subclasses can override if they wish. John _______________________________________________ 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
