Tracking This applies to 2 (or more) dimensional input devices. Tracking techniques are device dependant. What inputs are available during the tracking process? Positional inputs (2-d) Relative Mouse Track ball Atari joystick Absolute Tablet Joystick Touch screen Light pen Other inputs Buttons Keyboard Bucky bits Function keys Pressure What is tracking? The user describes a path with two endpoints with the input device The computer translates the path into the menu output, and provides visual feedback if necessary. How is tracking initiated? Specify the first endpoint Menu centered there. Button event Button down Down and up with no movement Touching a tablet or screen How is tracking terminated? Specify the second endpoint Menu output based on the angle and the distance between the two endpoint. Button event Button up Button down then up Withdrawing contact from a tablet or screen If the distance between the two endpoints is smaller than a certain distance, then nothing is choosen from the menu. After a mouse down has specified the first endpoint, if the next mouse up is in about the same spot, then instead of making a choice, keep tracking until the NEXT mouse up. If that mouse up is also in the same place, then the menu is cancled. This allows the user to choose from a menu in several ways: Mouse down and up in place, see the menu, move in a direction, mouse down and up to choose. Mouse down, see the menu, move in a direction, and mouse up to choose. Mouse down and up in place, see the menu, and mouse down and up in the same place again to cancle the menu. Know the menu, and mouse down and up while moving in the direction. How does tracking proceed? Follow the position of the cursor, showing what the output of the menu would be were the second endpoint placed there. Path Endpoint Tracking Based on the location of the endpoints of the path Compressibility of mouse events Only the endpoints of the path are needed Reliable mouse ahead. If both endpoints are already in the input queue, it is not necessary to display the menu. Dynamic Path Tracking Based on the path the mouse takes between endpoints. Output of menu may depend on the path taken, not just the endpoints SunView walking menus ??? Gorey implementation details Telling what slice the mouse is in Quadrant/slope 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. Also, at this point, it does trig, i.e. t = atan2(x, y), whenever you move the mouse, normalizing it such that 0 <= t < 1, and multiplying by the number of items to get the item number. I will fix this by dividing the menu into 4 quadrants, and calculating the boundries in terms of quadrant and slope in that quadrant upon initializing the menu. Each item will have a quadrant and slope field for one of its edges, and when you move the mouse, you just figure out its quadrant and slope by looking at the signs of x and y, and dividing. Then you look through the linked list of selections for the one it falls in. This eliminates all the trig except for setting up the menu. What I have already runs quite well on a sun-2, and roars on a Sun-3. 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? 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. Dealing with the screen edge Mouse warping Mouse wraping Menu display Pop up Pie Menus When to display? Don't need to display when the choice has already been made Static Pie Menus The menu is always displayed in a region of the screen. Mousing anywhere in the region warps the mouse to the center of the menu and proceeds tracking from there. Labeling Text Icons Pointers Wedges Continuous Highlighting Color Reverse video Color change Outline Pointer Icons Animation Submenus Show iconic version of submenus Show full sized when far out Mouse cursor shows choice while tracking Direct feedback Display the effect the menu would have while tracking