Plans [was: Re: Gconf or GSettings? - leading to a wider question]

[Linus Torvalds]

On Mon, Jan 21, 2013 at 6:57 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
>
> No, the maps.google.com implementation is correct - it doesn't "keep traveling" like the osmgpsmap implementation does.
> But playing with it some more, what I did is indeed the behavior that I think makes more sense for us as we center the map around the dive site. So zooming in and out around the dive site is much more natural.

That's only true in the single-dive map.

In the "world" dive map (^M) the zoom behavior is very non-intuitive
indeed. It's certainly better than the insane native OSM behavior, to
the point of making the widget usable, but it would be good to figure
out how to try to get the correct behavior.

Anyway, here's an example of how to do the iterative "zoom in at the
right point even if osm doesn't have that interface".

I'm not proud of it. It's a dirty disgusting hack, but it happens to
work. It makes several assumptions about the map, most notable of them
that the map translation is a pure cylindrical translation of
latitude/longitude. That happens to be right for OSM (at least the
form we use), so it seems to _work_, but it sure is hacky. It just
does a "let's try to center the map at random locations and see how
close we get to the target", where the "random locations" are just a
binary rectangular search.

The "binary rectangular search" is why it wouldn't work if OSM showed
the world using some other map projection than the purely cylindrical
one.

It also wouldn't work correctly if OSM did the right thing and wrapped
the world view - but again, OSM seems to do a pure rectangular mapping
of lat/long to x/y.

So this gets us the "correct" zooming behavior, but I want somebody
else to look at the code. If you can stand it, commit it and add my
sign-off. But I'll understand if anybody goes "that is too ugly to
live, please just nuke it from space, that's the only way to make
sure".

                        Linus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: application/octet-stream
Size: 2690 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130121/829ea911/attachment-0001.obj>