Subject: why 4 quadrants + slope?

From: Don Hopkins <[email-masked]>
Date: Fri, 26 Sep 86 06:25:26 EDT

More bullshit terminology:
Pie Menus are built up of Slices.

Assuming 0 <= angle < 360 points from the menu center to the mouse,
the mouse's quadrant is (angle div 90), and the slope is tan(angle mod
90). So the angle is 90 * quadrant + arctan(slope). The slope is more
convenient for tracking the mouse when you know its x and y offset
>from the menu center. You look at the directions of the offsets to get
the quadrant, and get the slope by dividing. The angle in degrees is
useful when setting up the menu and drawing the selections.  When the
menu is initialized, the slices' angles (both boundaries, and the
center) should be recorded, as well as the slope and quadrant
calculated for the boundaries (the previous boundary should have
already been calculated for all but the first slice, so don't
recalculate it unless you just want to waste time). All that
information should be easily and inexpensivly available.

You could have static pie menus: a region of the screen has a
picture of the menu, and mousing down and up in it invokes the slice
associated with the angle between a mouse down and mouse up events,
without popping anything up. 

Another way you might define the slice selected is: the slice in the
direction of the last mouse movement (or maybe some function of the
last n movements). Perhaps I should hack that up and see how it feels.
It does not have some of the advantages the other definition has, such
as finer control as you move out further. You do however change the
slice selected immediatly after you change the mouse direction, instead
of when you get move into its wedge. It might be useful for
certain things. (Possibly static pie menus.)

The Macintosh, just to name one example, has mouse sensative turds
along the top of the screen, which invoke pull down menus. PieMenus
must by able to elegantly handle menus that are invoked by mousing
near the edge of the screen... More thought has to be done on that.
Warping to the menu center, wherever that is after the menu has been
forced onto the screen, seem to be the best solution. I wallowed all
through the X sources in search of the mouse warping bug that I
described, but can't find it. It may be my uwm code that's the
problem, but it seems OK upon close inspection.  Maybe a good
rewriting would do it some good.

When the mouse has moved in a complete circle in either direction, the
menu being displayed could change.  So you could "wind" the menu in
either direction by "cranking" the mouse around in a circle (not
necessarily around the menu center). You consider a circle to have
been completed when theta (the direction from the mouse's previous to
its current point) crosses zero-crossing-theta, the value of theta
just after the last zero crossing of delta-theta (the angle formed
between the last two points the mouse was tracked at and its current
point). The direction of the circle is determined by the sign of
delta-theta (since the last zero crossing). I can see how the
algorithm could be frobbed to ignore circles with a curvature
(delta-theta) above a certain number by resetting zero-crossing-theta
when abs(delta-theta) is greater than some threshold (as well as when
it crosses zero), or to be more tolerant of wishy-washy circles and
random noise by defining delta-theta as some function of the last n
points, or to reset zero-crossing theta when length of the last n mouse
movements is below a threshold.

	-Don