For pie menus to be religiously correct, there needs to be a concise definition of what a pie menu actually is. On top of that, the implementation has to actually conform to that definition in all cases. Here are some definitions: The selection made from a pie menu is based upon the angle between the position of the mouse down event (the menu center) and that of the mouse up event. A mouse button event specifies the position of the mouse at the time of the event, the button involved, and whether it was up or down. In some cases, the button specification might include other information such as bucky bits in effect at the time of the event. Bucky bits describe the set of modifier keys being held down, such as Control, Meta, Shift, Command, Function, Computer Manufacturer Logo, etc... Mouse events are asynchronous. They cause interrupts, at which time the pertinent states are recorded in the event, and the event is put into a queue. The current mouse position is continuously updated whenever the mouse moves. There may be unprocessed, pending mouse events in the queue that correspond to locations that the mouse was at before it was at the current position. Warping the mouse changes the current position of the mouse cursor on the screen to a new location, without any corresponding movement of the physical mouse. It does not change the positions associated with any pending mouse button events that are already in the queue at the time of the warp. Here are some problems I had adhering to the definition of pie menus, and the solutions I came up with: Mouse button down events near enough to the edge of the screen may invoke a menu, that when centered on the location of the event, would not completely fit on the screen. It is important to have the whole menu on the screen for two reasons: so all the selections are visible, and more importantly, so that they are all choosable. The canonical solution is to force the menu to be within the confines of the screen, by moving it by an appropriate offset. The problem with this solution was that in moving the menu, the center of the menu by which the selection was defined was moved. This would leave the mouse in other than the menu center. This violates the definition of pie menus. The obvious solution to that was to warp the mouse to the center of the menu if the menu had to be centered on a different place than the mouse down event. The problem with that was that is that mouse movement between the time of the mouse down event, and the time when the mouse was warped, is lost. My initial solution to that problem was to look at the offset between the mouse down event and the current mouse location, and warp the mouse to the center of the menu plus that offset. There are things to consider when there are pending mouse events that had not already been acted upon. If, at the time the mouse down event is received, the mouse up event that completes the selection is already pending, then there is already enough information to make the selection. It is not appropriate to look at the current mouse position, because the selection has already been completely specified. At this point, putting the menu up serves no purpose but feedback, and slows down interaction. The selection can be made and acted upon without even showing a menu, if feedback is not required, or if acting on a selection provides the feedback. The interaction between mouse warping and pending mouse events create weird problems. If you warp the mouse when there are pending mouse events, the positions associated with those events are still relative to the unwarped mouse position. The angle towards the pending mouse up event that specifies the current selection is different after the mouse has been warped. Also, if the last pending event is a mouse down, the angle between that event and the current mouse position changes. My solution is to only put up a menu when there are no pending mouse button events. That makes it unnecessary to warp the mouse if that menu would occur near the edge of the screen. When there are events pending, they are acted upon without putting up a menu. When there are not, and more are needed to complete a selection, a menu is actually put up. If the menu would not fit completely on the screen, it is moved by the appropriate offset back onto the screen, and the mouse is warped to its current location plus that same offset. The mouse's current location is then tracked until the mouse up event occurs, at which time the selection is made. During tracking, the selection that would be made were the mouse button be let up at the current mouse position is highlighted. Another solution the to the screen edge problem could be to have the mouse wrap around to the opposite edge of the screen when it moves off. When tracking Pie Menus, you would look at the actual displacement that the physical mouse moved from the center of the menu, not the position the cursor was wrapped to on the screen. You can only warp relative input devices.