Sander van Grieken <[email protected]> writes: > On Friday 21 May 2010 15:44:02 Joshua Judson Rosen wrote: > > John Stowers <[email protected]> writes: > > > > > > The limitation appears to be the assumption that the same pixbuf be > > > used as a handle for a group of pois/images. Is this something that is > > > useful/true in practice or will the app still need to keep around the > > > pointer to each added poi/image anyway (in which case we might as well > > > keep the implementation simple, and thus remove() only accepts the > > > opaque pointer) > > > > > > What do you think? > > > > Speaking only for FoxtrotGPS, I have a patch that I'm going to want to > > integrate at some point that enables distinct items in the same general > > class (e.g.: different POIs) to have have different icons; so > > we're ultimately not going to find much use in osm-gps-map's > > current remove_image() behaviour. > > > > For maximal flexibility,
... while (I meant to say) trying to preserve ease of use... > > I'd probably also add a `user_data' member to image_t, add an > > add_image_with_data() function that associates its `data' argument > > with the newly_created image_t, make add_image() associate the > > newly-created image_t with *itself* and return the same pointer; > > then you can drop the old GdkPixbuf argument from remove_image(). > > It'd also be good to add a foreach_image() function that can be > > used to to iterate over all of the images with at least a > > 2-argument (key, userparm) callback like they have in various > > places in GLib and GTK+. ... or something like that. > Why would you want to put so much image management functionality in > osm-gps-map? We need to manage these things in the application > anyway, in order to know what to put in and take out of the view, if > it's being clicked on, etc. There are a few different answers (or parts to a single answer) for this. One is, "Well, *we* do in foxtrot, but I don't know about everyone else with other applications using osm-gps-map". My response was poorly-phrased, and I should have more clearly delineated the "speaking only for foxtrot..." paragraph vs. the rest of the response. Another is that it's not image-management, it's collection-management; and osm-gps-map has already taken on the responsibility of managing the collection by hiding it behind a PIMPL. If it doesn't provide a sufficient API to interact with the opaque collection(s), that can cause problems even for applications that are willing to handle a lot of details themselves. For example: > If osm-gps-map simply provides the add/remove image functions that > work with unique image_t* pointers for each image instance, we can > manage everything from the outside. The code is already there. If > you want many more different icons, that should be no problem since > we can already pass any pixbuf. It's easy to add them--that's not the problem; the issue is managing the collection once it's populated; `remove or replace a subset of icons', for example, currently cannot be implemented by client code in anything better than O(n**2), because every call to remove_image() potentially needs to traverse the entire GSList. Also, I'm not sure, but I wonder if it might actually cause a lot of superfluous redraws. > It was on my wishlist too BTW, these POI class specific icons, We already have 2 classes/groups of icons: POIs and people.... -- "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))." _______________________________________________ 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
