[GRASS-dev] Vote for your favorite zoom out

GRASS GIS GRASS GIS developer
1

Zooming in with a zoom box is pretty straight forward. But zooming out is
conceptually and computationally somewhat more complex, and is done in
various ways (or not at all) in other graphics/GIS programs.

After working off list on various approaches to zooming out with a zoom box,
I want to give you all several alternative proposals and let you vote on
them. It gives us a chance to try out the voting procedure. I think that
we¹d said that we¹d have 2 or 3 days. Since it¹s the weekend, I¹ll take
votes through Tuesday Arizona time (Markus, if this is too short a time,
please let me know and I¹ll extend it.). I¹ll try to get this in the cvs as
soon as possible after Tuesday.

Vote for options (I¹m willing to do either 1a/b or 2a/b, and personally
favor variants 1a or 2a):

1a: 1+
1b: 0+
2a: 1+
2b: 0+
3: 1-

.....................

Here is an explanation of the options:

1a. The current region is fit into the zoom box where the zoom box is drawn:

1b. The current region is fit into the zoom box and centered in the display:

Issues: This is the easiest to explain and the most directly opposite of a
zoom in box (where the box defines the new region extents). The box defines
the amount of zoom in (i.e., new region extents) in both dimensions. The
main drawback is that the resulting region geometry (aspect ratio) is the
inverse of the box geometry. Because the smaller the box, the more the
region is extended (to make the original region appear smaller in the
display). This means that a tall, narrow box will extend the region a lot in
the E-W dimension and less in the N-S dimension, producing a short, wide
region. If we go to this, kind of zoom out, I like 1a because it gives the
user even more control over zooming (kind of zooming and panning in one fell
swoop), though is more complicated. However, if 1b gets more votes, I¹ll go
with that instead.

2a. The box directly defines the geometry of the new region and the box¹s
longest dimension determines the amount zoomed out (how much the region is
extended to make the current map appear smaller). The new region is centered
in the display. That is, a long, short box will produce a long, short region
that is larger than the original region (making the map appear to be
smaller).

2b. The box directly defines the geometry of the new region and the box¹s
shortest dimension determines the amount zoomed out. The new region is
centered in the display.

Issues: Unlike zooming in, the zoom out is controlled only by a single box
dimension, giving the user less control. However, the resulting region
matches the geometry of the zoom box, with might be more what a user has in
mind. To my mine, 2b zooms out too fast, which is why I prefer 2a. For
example, a long, narrow zoom out box will produce a slightly zoomed out,
long, narrow region with 2a, but a very zoomed out, long, narrow region with
2b.

3. The box causes the the display to zoom out, but either does not control
the amount of zoom out (e.g., region is extended by some set amount) or
doesn¹t control the region geometry (e.g., the display window controls the
geometry regardless of the shape of the zoom out box).

Issues: I see no point in going to the trouble of coding a zoom box if it
doesn¹t give a user control over the region extents (i.e., both the amount
of zoom and the resulting region geometry). We already have a nice quick,
1-click zoom in and zoom out that I¹ve cleaned up a bit more over what is
now in the cvs.

...................

In all cases, drawing a zoom out box outside the region extents or a zoom
out box whose geometry is very different from the existing region geometry
may produce visual results that are a little odd, even when the zooming is
following the rules correctly. I can put in some traps for this depending on
the algorithm used. However, in any case, it *will* zoom out, allowing the
user to see more of the map than before and other tools (quick 1-click
zooming or zoom in box) can be used for fine tuning if needed.

So let the voting begin

Enjoy
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

2

On Sun, October 1, 2006 08:25, Michael Barton wrote:

2a. The box directly defines the geometry of the new region and the box¹s
longest dimension determines the amount zoomed out (how much the region is
extended to make the current map appear smaller). The new region is
centered
in the display. That is, a long, short box will produce a long, short
region
that is larger than the original region (making the map appear to be
smaller).

2a: +1

Moritz

3

Michael Barton wrote:

Zooming in with a zoom box is pretty straight forward. But zooming out
is conceptually and computationally somewhat more complex, and is done
in various ways (or not at all) in other graphics/GIS programs.

After working off list on various approaches to zooming out with a
zoom box, I want to give you all several alternative proposals and let
you vote on them. It gives us a chance to try out the voting
procedure. I think that we¹d said that we¹d have 2 or 3 days. Since
it¹s the weekend, I¹ll take votes through Tuesday Arizona time

two points re voting. a) IMO 2-3 days is too short, 4-5 days is a better
compromise between non-stalling & inclusiveness b) I really hope that
any formal voting proceedure doesn't stop anyone who doesn't vote from
speaking up if they have an opinion or new idea.

Vote for options (I¹m willing to do either 1a/b or 2a/b, and
personally favor variants 1a or 2a):

1a: 1+
1b: 0+
2a: 1+
2b: 0+
3: 1-

write in vote: option 4. (call it 3b if you want)

3. The box causes the the display to zoom out, but either does not
control the amount of zoom out (e.g., region is extended by some set
amount) or doesn¹t control the region geometry (e.g., the display
window controls the geometry regardless of the shape of the zoom out
box).

Issues: I see no point in going to the trouble of coding a zoom box if
it doesn¹t give a user control over the region extents (i.e., both the
amount of zoom and the resulting region geometry). We already have a
nice quick, 1-click zoom in and zoom out that I¹ve cleaned up a bit
more over what is now in the cvs.

4. No zoom out by box. Zoom out click (right click from zoom-in?)
zooms out by a factor of 2 or sqrt(2) [or something in between].
New region is centered on location of the click. bounds change but
resolution is preserved.

A couple problems with zoom out by box:

- it's friggin confusing for us to decide what it means, think of how
the user will cope.

- it's easy to try and single-click to zoom out, but actually draw a
1x1 pixel box, and zoom out like mad. I *always* do this when using
software with zoom-out by box and it drives me nuts.

- conceptually you are drawing a box on the window glass, and ignoring
what's behind the glass [ie imagine what the new map will look like in
real time, then draw your box on that mental projection after rescaling
and placing the current display map in your head...]. This is a totally
different place to put your brain vs. zooming in where you are using a
direct god's eye view. When quickly zooming in+out to get just the right
area this duality makes your head spin, or at least slow you down when
you jump the groove.

I can see the advantage of using a zoom-out box if you want to ever so
slightly zoom out, but the click to zoom-out by sqrt(2), and redoing a
zoom-in box ain't so bad.

I argue for the right click to unzoom when in zoom-in mode for speed
to final result. (probably in addition to a formal zoom-out button)

e.g.

- left click zooms in by 2 or sqrt(2) immediately
- left click drag zooms in to box, highlights box but doesn't zoom yet
   (gives you a chance to try again)
- middle click accepts highlighted zoom-in box & redraws
- left or right button click while highlight box is up cancels the box
   and does nothing to the zoom (escape route)
  left click drag draws a new box
- right click zooms out by 2 or sqrt(2)

now you may be thinking this is as confusing as the current xmon
prompts, but those not in the know can still click to zoom in/out.

keyboard click for zoom-out ain't so bad for 1 button applers.
keyboard clicks for zoom-in box is not intuitive for applers, but not
disabling as single click to zoom still works. but it kinda sucks.
("gis requires at least 3 buttons. spend the $10. not long ago GIS
   digitizing pallets were 4-12 buttons")
Photoshop's authors probably have the same UI nightmares on Mac.

without getting into platform wars, I always saw the single button mac
mouse more as a way to force developers to come up with easy to use
interfaces (like now), but much less useful for a user. We have 5
fingers after all, and know how to use them to do different things.
All users win a lot in the forced good design with a single button mac,
but the power user is slowed down some. This doesn't mean a 3 button
mouse is bad to use!

2c,
Hamish

4

[No, I don't vote, but since I'm still reading the mailing
list---usefull at least to compare my options with yours or to pick up
good ideas---I just give the following information]

On Mon, Oct 02, 2006 at 09:37:04PM +1300, Hamish wrote:

4. No zoom out by box. Zoom out click (right click from zoom-in?)
zooms out by a factor of 2 or sqrt(2) [or something in between].
New region is centered on location of the click. bounds change but
resolution is preserved.

FWIW, in the original v.digit(1) (and present in the KerGIS version)
was the "widen window" option. It's zooming out by displaying a color
rectangle representing the whole map with a rectangle wire locating the
current window. Then you only select another window knowing both the
whole extend, and where you were before.
It's far more handy, since it's simpler to zoom out loosely, and then
zoom in precisely.

I didn't understand why this was nuked in GPL GRASS version.

Cheers,
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

5

This already exists. No need to right click. Just select zoom out tool and
click. The centering is already done and will go into the cvs as soon as the
box algorithm is decided.

People have already talked a lot on zooming and I'm sure they will some
more. The other points you raise about middle and right clicking, for
example, were discussed a lot a few months back and I'm certain they will
come up again. There's no way to restrict such discussion, even if someone
wanted to :wink:

However, the idea of voting (I thought) was to actually make a decision and
move on--at least for the nonce.

I have no trouble about extending the voting, especially for momentous
decisions like this :-). I was just trying to remember what the previous
discussions suggested. Also, I was (selfishly) looking at my personal
schedule to see when I could squeeze in getting this into the cvs.

Let's go through Wednesday.

Cheers
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Hamish <hamish_nospam@yahoo.com>
Date: Mon, 2 Oct 2006 21:37:04 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Vote for your favorite zoom out

4. No zoom out by box. Zoom out click (right click from zoom-in?)
zooms out by a factor of 2 or sqrt(2) [or something in between].
New region is centered on location of the click. bounds change but
resolution is preserved.

6

2a: +1, proviso a boxsize threshold, maybe 2px x 2px in order to
prevent the "zoom out to the whole universe" syndrome

Daniel.

--
-- Daniel Calvelo Aros

7

Michael Barton wrote:

This already exists. No need to right click. Just select zoom out tool
and click.

A point I was trying to make is that selecting another tool is slow when
the task is zooming in & out to get the region "just right". That's why
I wanted right click zoom-out in addition to the formal zoom out tool.
Optional keyboard shortcuts to tools sort of help but are impossible to
remember.

There's no way to restrict such discussion, even if someone wanted to
:wink:

nope, but you can happily ignore the noise & get on with the coding.

We used to have a system at the shop I used to work in- the last person
who turned up in the morning got to pick the radio station for the rest
of the day (the radio was near the coat rack). It worked pretty well.

Hamish

8

From: Hamish <hamish_nospam@yahoo.com>
Date: Tue, 3 Oct 2006 16:35:51 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Vote for your favorite zoom out

Michael Barton wrote:

This already exists. No need to right click. Just select zoom out tool
and click.

A point I was trying to make is that selecting another tool is slow when
the task is zooming in & out to get the region "just right". That's why
I wanted right click zoom-out in addition to the formal zoom out tool.
Optional keyboard shortcuts to tools sort of help but are impossible to
remember.

Agreed. If you already know this and meant something else, please just
disregard. What I meant to say is that it's the same tool. Click and drag to
draw a zoom box. Just click and it simply zooms out by a set amount. No need
to change tools.

There's no way to restrict such discussion, even if someone wanted to
:wink:

nope, but you can happily ignore the noise & get on with the coding.

We used to have a system at the shop I used to work in- the last person
who turned up in the morning got to pick the radio station for the rest
of the day (the radio was near the coat rack). It worked pretty well.

I like that. Now if I could just get the first person in the lab to make the
coffee....

Cheers
Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

9

Thierry Laronde wrote:

FWIW, in the original v.digit(1) (and present in the KerGIS version)
was the "widen window" option. It's zooming out by displaying a color
rectangle representing the whole map with a rectangle wire locating
the current window. Then you only select another window knowing both
the whole extend, and where you were before.
It's far more handy, since it's simpler to zoom out loosely, and then
zoom in precisely.

I didn't understand why this was nuked in GPL GRASS version.

do you mean the mode present in GRASS 5's v.digit, or was there
something else present in the pre-GPL days?

(then "nuked in the GRASS 6 version of v.digit", nothing to do with GPL
adoption with version 5.0)

Hamish

10

tlaronde@polynum.com wrote:

FWIW, in the original v.digit(1) (and present in the KerGIS version)
was the "widen window" option. It's zooming out by displaying a color
rectangle representing the whole map with a rectangle wire locating
the current window. Then you only select another window knowing both
the whole extend, and where you were before.
It's far more handy, since it's simpler to zoom out loosely, and then
zoom in precisely.

I didn't understand why this was nuked in GPL GRASS version.

or how i.points does it?

Hamish

11

On Tue, Oct 03, 2006 at 04:52:11PM +1300, Hamish wrote:

Thierry Laronde wrote:
> FWIW, in the original v.digit(1) (and present in the KerGIS version)
> was the "widen window" option. It's zooming out by displaying a color
> rectangle representing the whole map with a rectangle wire locating
> the current window. Then you only select another window knowing both
> the whole extend, and where you were before.
> It's far more handy, since it's simpler to zoom out loosely, and then
> zoom in precisely.
>
> I didn't understand why this was nuked in GPL GRASS version.

do you mean the mode present in GRASS 5's v.digit, or was there
something else present in the pre-GPL days?

Existing in the pre-GPL days. I first used GRASS in the GPL version 5.0.
It was already not there.

(then "nuked in the GRASS 6 version of v.digit", nothing to do with GPL
adoption with version 5.0)

Hamish

And the "GPL GRASS" mention is not a criticism, nor the claim that this
was nuked because of the licence. It's only for me the standard way to
name the different branches from GRASS (the original public domain), to
GPL GRASS (your version) and BSD GRASS aka KerGIS (my version). Sorry if
it seemed deprecating, it was not the intention.

Since there _are_ main differences between the GPL GRASS and the
original, we (or at least I) feel the need to name exactly what version
I'm referring to.

Cheers,
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

12

On Tue, Oct 03, 2006 at 04:53:09PM +1300, Hamish wrote:

or how i.points does it?

No, it's different.

And part of the hard work for me is precisely to put the zooming
functions (based on the DRAWLIB [previously named RASTERLIB] and
CURSESTKLIB [previously named VASKLIB]) into one toolkit lib so that
there is, when possible, one zooming version consistent accross the
different graphical programs.

Cheers,
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

13

On Tue, Oct 03, 2006 at 12:39:14PM +0200, tlaronde@polynum.com wrote:

On Tue, Oct 03, 2006 at 04:53:09PM +1300, Hamish wrote:
>
> or how i.points does it?

No, it's different.

And part of the hard work for me is precisely to put the zooming
functions (based on the DRAWLIB [previously named RASTERLIB] and
CURSESTKLIB [previously named VASKLIB]) into one toolkit lib so that
there is, when possible, one zooming version consistent accross the
different graphical programs.

From a user's prespective, this sounds very good.

Markus

14

Michael Barton wrote:

> Michael Barton wrote:
>> This already exists. No need to right click. Just select zoom out
>tool > and click.
>
> A point I was trying to make is that selecting another tool is slow
> when the task is zooming in & out to get the region "just right".
> That's why I wanted right click zoom-out in addition to the formal
> zoom out tool. Optional keyboard shortcuts to tools sort of help but
> are impossible to remember.
>

Agreed. If you already know this and meant something else, please just
disregard. What I meant to say is that it's the same tool. Click and
drag to draw a zoom box. Just click and it simply zooms out by a set
amount. No need to change tools.

I was trying to say: allow zoom *OUT* using a right click when using the
zoom *IN* tool.

Hamish

15

> Thierry Laronde wrote:
> > FWIW, in the original v.digit(1) (and present in the KerGIS
> > version) was the "widen window" option.

..

> > I didn't understand why this was nuked in GPL GRASS version.
>
> do you mean the mode present in GRASS 5's v.digit, or was there
> something else present in the pre-GPL days?

Existing in the pre-GPL days. I first used GRASS in the GPL version
5.0. It was already not there.

ok, got it.

I was wondering if you were differentiating between GRASS 4 and 5 or
more generally GPL GRASS (ver5&6) and KerGIS bases.

And the "GPL GRASS" mention is not a criticism,

not taken as such.

Since there _are_ main differences between the GPL GRASS and the
original, we (or at least I) feel the need to name exactly what
version I'm referring to.

And it's good to do so. I didn't realize the v.digit in GRASS 5 was new
for GRASS 5.

And part of the hard work for me is precisely to put the zooming
functions (based on the DRAWLIB [previously named RASTERLIB] and
CURSESTKLIB [previously named VASKLIB]) into one toolkit lib so that
there is, when possible, one zooming version consistent accross the
different graphical programs.

aside: will KerGIS stick with Curses/TclTk for the GUI or switch to
something more "modern"?

Hamish

16

On Wed, Oct 04, 2006 at 02:17:02PM +1300, Hamish wrote:

aside: will KerGIS stick with Curses/TclTk for the GUI or switch to
something more "modern"?

KerGIS doesn't use TclTk and won't.
I use the term "tk" for "ToolKit", but this has nothing to do with
TclTk. This is simply a naming scheme to show that some library is
a tool kit library built upon a more basic set of facilities
(cursestk is the tool kit built upon Curses, and was called VASKLIB).
The basic libraries are found in lib/, and the toolkits in usr/lib.

The aim is to clearly separate processing of data from interfaces.
There will be, finally, 3 versions and, if done correctly, people
wanting another interface could do it easily (when the split is
done) :

Cursestk/Drawlib /* DRAWLIB was RASTERLIB. This one exists */

Athena/Drawlib /* because Athena is standard with X distribution */

Motif/Drawlib

In fact, using the references for curses and the Athena widget (both are
simple) is a good help to see the common things about the gestion of
windows, and is not a bad idea before going to something more complex.
And I want to stick strictly to C, hence the choices.

The 3 will give exactly the same possibilities (with the same shortcuts)
even if the interfaces are obviously quite different. On working on this
I will see if it is possible to derive the 3 versions from some kind of
common description (I have some very fuzzy ideas at the moment,
experience will tell if it is achievable or not; but the first step is
to separate processing from interface, in v.digit(1) for example).

I don't plan to drop the curses interface: it has its uses, and text
menus (with short cuts) contrary to pixmap buttons are something I
personnally like (I have a huge experience with CAD programs that I use
almost exclusively with keyboard, whether shortcuts or typing commands
--- Microstation for example; and in fact I want to add a command line
with a basic interpreter to v.digit(1) for example to launch facilities
on the map displayed [or to register the operations for replay or undo]).

The work on the interfaces is planned for after the release of 1.0. (not
for 1.0 that has already been delayed too much).

KerGIS has less requisites than GPL GRASS since it is aimed to run on a
POSIX node, period (I don't care about Windows users: if they want to be
able to run it they have to provide a POSIX environment
and this is their problem, not mine), and since only X Window will be
supported by default (others can port the DRAWLIB to other things if
they want).

But I'm a freak :wink:
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

17

OK. Now I understand you. Sorry for being dense.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Hamish <hamish_nospam@yahoo.com>
Date: Wed, 4 Oct 2006 13:59:53 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Vote for your favorite zoom out

Michael Barton wrote:

Michael Barton wrote:

This already exists. No need to right click. Just select zoom out

tool > and click.

A point I was trying to make is that selecting another tool is slow
when the task is zooming in & out to get the region "just right".
That's why I wanted right click zoom-out in addition to the formal
zoom out tool. Optional keyboard shortcuts to tools sort of help but
are impossible to remember.

Agreed. If you already know this and meant something else, please just
disregard. What I meant to say is that it's the same tool. Click and
drag to draw a zoom box. Just click and it simply zooms out by a set
amount. No need to change tools.

I was trying to say: allow zoom *OUT* using a right click when using the
zoom *IN* tool.

Hamish