From don@brillig.umd.edu Mon Jan 12 23:04:28 1987
Date: Thu, 18 Sep 86 05:02:47 EDT
From: Don Hopkins <don@brillig.umd.edu>
Cc: don@brillig.umd.edu, unipress!mg@topaz.rutgers.edu
Subject: Pie menu ideas, and the punch line ...

I changed uwm so that it does not warp the mouse to the center of the
menu when it puts it up. I had originaly done this because I wanted to
always start in the middle of the menu, but what I really want is for
the selection to be based on the angle of the movement from mouse down
to mouse up, not from menu display to mouse up. The response it now a
lot better (i.e. the movement between mouse down and menu display is
not ignored), and you get effective "mouse ahead". I have to bog down
a Sun and see how well it performs then. That was when the warping
version was lusing. It also makes for more reasonable behavior near
the edges of the screen, due to an X bug in mouse warping I have have
not been able to track down.  Currently, if you invoke a menu where
part might fall off the screen, it is moved so that it all fits onto
the screen. This moves the center of the menu away from where the
mouse down event was. The mouse was being warped to the middle, but as
soon as you moved, it mysteriously warped back to where it was at the
mouse down event. Without warping, it starts out with the selection in
the direction of the mouse down event from the new menu center
highlighted.  This is better than what is WAS doing, but still not
optimal. Do you think the menu shouldn't be forced to be completely on
the screen? Should mouse tracking during menu selection allow the
mouse to leave the screen? Or should it warp the mouse to
new_menu_center + (mouse_down_location - current_mouse_location)?
(Assuming the warp drive is operational.)

Menus can be displayed as labeled icons around the menu name label in
the center, which may have arrows, spears, wedges, or other
embelishments around it. For entries that invoke a submenu, the icon
for the entry could be an scaled down image of the menu that it
invokes (possibly with less detail) so that you can know by looking at
the first menu what the next stroke should be. Alternativly, just the
name of the submenu and maybe an icon could be displayed, but when
tracking the mouse, selections that are menus would be highlighted by
drawing the mini-menu. This might look less cluttered. When a submenu
is selected, its mini-menu would zoom to normal size, and the parent
menu could either vanish or stay underneath.

A menu that would work well in miniature form as a submenu:
			______
			|    |
			|    |
			|    |
	______		|    |
	|    |		|    |
	|    |		| 60 |
	|    |		|    |		______
	|    |		|    |		|__6_|
	| 48 |		|    |
	|    |		|____|	
	|    |			
	|____|	     Window Height
	______			
	|    |				______
	|    |		______		|    |
	|    |		|    |		|_12_|
	| 36 |		|    |
	|    |		| 24 |
	|____|		|____|

You could choose from a set of 6 commonly used window sizes, with each
being in a unique direction, or you could choose any intermediate
value in between, by not constraining the choices to 6 sizes.

One thing that should be explored is the philosophy of convenient
directions. What does it mean for a direction to be convenient?
Easy to remember is convenient, but are there directions that are
easier to specify with a mouse, touchpad, joystick, trackball,
lightpen, footmouse, or whatever? Under what circumstances does a
direction's convenience differ? 

A selection's position relative to other selections is an important
factor. A selections could be placed opposite of one that complements
it, and 90 (or whatever) degrees away from ones that are orthogonal to
it.  What other ways are there to make selection directions easy to
remember are there?

I think the following menu demonstrates this philosophy:

			   Any Height
	   Any Size			    Next Size

    Any Width		   Window Size		Common Width

	Previous Size			   Common Size
			  Common Height

A graphical representation could show a small version of each submenu,
as well as the text label. The Common menus might have pointers
showing the direction of each icon, while the Any menus would have
the icons but not the arrows.

There could be another menu to choose a window size from a window's
size ring (like an emacs kill ring: a circular array with one "current
item" (displayed at the top of course)), and a way add and delete
sizes. i.e. a size ring menu, where you choose a verb (select,
replace, add, delete, next, previous, etc), and then (if appropriate)
a noun (by selecting one of the sizes depicted in a menu). With the
current item at the top, operations on the current item would always
be the same sequence of strokes. This could be applied to rings of
whatever you want.

Another similarly arranged set of menus could let you scale windows
without changing the number of lines or columns. (i.e. change the font
size.)

I am going to write the mouse tracking code next, and feed it some
fake mouse actions as a test, and print out a "movie" of what would
happen. Maybe I can cut them out and staple them together to make a
flip-em cartoon. 

To make mouse tracking much more efficient, when the mouse angle
changes, the current then the neighboring selections should be compared
against the new angle. No reason to start from the top of the list of
selections each and every mouse movement. I'm thinking about efficient
ways to do a fast binary search by first looking at sector numbers,
and then at slopes when you've homed in. But if x% of the cases of
mouse movement leave you in the same sector, y% in a neighbor, and z%
somewhere else, and (pardon the ad hoc notation) x < y <<<<<<<< z , is
it worth the extra effort? The solution should work for degenerate cases
(two, one, or even zero items) to be truly elegant.

Another thing to think about is how to represent the angle more
efficiently. Instead of quad = {0,1,2,3} and 0 <= slope < infinity, how
about quad = {0, 1}, and -infinity < slope < infinity ...? I don't
think you could not describe straight up and down (or wherever)
though. Is there a clever way to encode that? Or is it really
worthwhile? 

What do you think about confering with James Gosling about making pie
menus fit into SunDew? Also, is there any news on the Sun Users Group
meeting? I think it would be quite benificial to attend.

Simple Simon popped a Pie Men-u up on the screen.
With direction-al selection, all was peachy keen!

	-Don