[FOSS-GPS] Instance-IDs for osm-gps-map's `image' API

[Joshua Judson Rosen]

Sander van Grieken <sander at 3v8.net> writes:
> On Friday 21 May 2010 15:44:02 Joshua Judson Rosen wrote:
> > John Stowers <john.stowers.lists at gmail.com> 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))))."