Michael Barton wrote:
On 12/22/06 12:52 PM, "Maciej Sieczka" <tutey@o2.pl> wrote:
With regard to one-click zooming, it works exactly as it is designed to
work.
Do you mean that the single click zoom is *not* supposed to preserve
the initial region aspect ratio in the *constrained* zoom mode?
I'd appreciate a short, straight answer.
I've said this a couple times on the list, but perhaps you've
missed it.
I'll take for a joke.
???
I thought the answer above was pretty short and straight. Here is my post of
27 November on this in its entirety. It's somewhat longer, but should
suffice.
Your message you quote below is not an answer to my question. I will
ask it again and, again, kindly ask you for a short, straight reply:
Do you mean that the single click zoom is *not* supposed to preserve
the initial region aspect ratio in the *constrained* zoom mode? Arguments?
A hint: if the single click zoom is *not* supposed to preserve the
initial region aspect ratio in the *constrained* zoom mode, then how
does it differ, in terms of the look of the map in the Map Display,
from the *unconstrained* mode?
See how d.zoom behaves. It allows for a single click zoom-out (middle
mouse key), and it *does* preserve the initial region aspect ratio
then. That's how gis.m's single click zoom tool *should* behave as
well. Isn't that logical for you? Why do you prefer it not preserving
the initial aspect ratio, like if it was the *unconstrained* mode???
Find more relpies below.
From: Michael Barton <michael.barton@asu.edu>
Date: Fri, 17 Nov 2006 08:16:04 -0700
To: Markus Neteler <neteler@itc.it>
Cc: <grass-dev@grass.itc.it>, Hamish <hamish_nospam@yahoo.com>
Conversation: [GRASS-dev] fixes before 6.2.1 [was: ps.map: scale wrong and no
output]
Subject: Re: [GRASS-dev] fixes before 6.2.1 [was: ps.map: scale wrong and no
output]
This is not a bug.
No, you only *think* this is not a bug, because you designed the tool
wrong and it performs according to your wrong design. The problem is
the design was wrong.
A similar situation would be if you wrote a calculator program, which
you designed to calculate 2+2 as 5. Obviously, the result would be
wrong in terms of truth and reasonable user's expectations, but your
argument would be that this is not a bug, because you designed it to
calculate 2+2 as 5 instead of 4, and it works as you designed it.
It is hard to argue with you because you look at complicated problems
only from your very own perspective, and hardly accept a reasonable
argument of someone else. Unless it is Glynn :). Let me remind you of
the issue with gis.m's box-zoom tool not maintaining the region
properly. I kept telling you about this problem for circa 3 months, and
you kept denying it. Until Glynn spoke up, after which you fixed the
tool according to his suggestion quite soon. When it was me, you just
kept treating me as an annoying pest. And to get rid of me you flooded
me with longish elaborates, which often didn't address the concerns and
looked like if you didn't understand the problem, or didn't want to
understand it.
Now you act the same. And you even repost your past replies, or make me
look for them in the archives myself, advertising them as an "answer".
It is driving me nuts that you are waisting my (and your) time. And all
I can do then is take it for a joke.
I'm sorry if I'm not making myself clear. I'm not a native English
speaker. Writing an understandable, detailed problem report is a
substantial effort for me. I'm writing them not to tease or piss off
people, but to help. Please respect this.
The single click zoom in (and out) uses the window geometry
to zoom in to fill the display as you get 'closer', while centering the view
(i.e., display region) on the point you click.
That's the problem. It shouldn't "fill the display as you get
'closer'". It should preserve the initial region aspect ratio instead,
because it is the *constrained* zoom mode, not the *unconstrained* one.
You can set the aspect display
geometry with a box or with g.region--or you can simply make the display
window the aspect geometry you want and single-click away.
This takes using more tools than needed, thus it is a sub-optimal
solution; a workaround, actually.
It works like the zoom in/zoom out button that GRASS lacks. IMHO, it's
pretty slick. While some might wish
Another bad practice, please don't do it. Don't understimate my
reasonable problem report as a "wish", a feature request.
it were otherwise, it is this way with forethought and intention,
and works exactly as designed--so not a bug.
See my notes above about the wrong desing as a bug.
Maciek