[GRASS-dev] Holiday GUI updates to GRASS

Maciej Sieczka tutey at o2.pl
Sun Dec 24 07:05:44 EST 2006


Michael Barton wrote:
> On 12/22/06 12:52 PM, "Maciej Sieczka" <tutey at 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 at asu.edu>
>> Date: Fri, 17 Nov 2006 08:16:04 -0700
>> To: Markus Neteler <neteler at itc.it>
>> Cc: <grass-dev at grass.itc.it>, Hamish <hamish_nospam at 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




More information about the grass-dev mailing list