Turning a dial is a totally different gesture than making directional strokes, so they are different beasts, and a dial lacks the advantages pie menus derive from exploiting Fitts's Law.

https://en.wikipedia.org/wiki/Fitts%27s_law

Even though the Surface Dial has a round dial, that is nothing like a pie menu, even though it's round, because you turn it. Pie menus aren't about turning around the center, they're about stroking out from the center.

Also a rotating carousel or rocker switch that you turn or nudge clockwise or counterclockwise to change between different items, and then click to select an item, is not anything like a pie menu.

You have to turn a dial or carousel more and more to select each subsequent item. (Just like you have to move the cursor more and more downwards to select each subsequent item of a linear pull-down menu).

With pull down menus, click wheels and carousels, selection is linear O(n), while with a pie menu you only have to perform one short directional gesture to select any item, so selection is constant O(1) (with a small constant, the inner inactive radius of the hole in the middle, which you can make larger if you're a spaz).

Also, the items themselves should never rotate around the menu (unless you're doing some quick transient snazzy spin-up animation), they should always stay in the same direction.

Here are some window management pie menus that spin up if you click them up without moving, and tilt up around the axis perpendicular to the direction of motion, if you move away from the center before they pop up:

https://www.youtube.com/watch?v=tMcmQk-q0k4

Stallman likes to classify an emacs-like text editor that totally misses the point of emacs by not having an extension language as an "erzatz emacs". In the same sense, there are many "erzatz pie menus" that may look like pie menus on the surface, but don't actually track or feel like pie menus, or benefit from all of their advantages, because they aren't designed to optimize for Fitts's Law by being based purely on the direction between stroke endpoints instead of the entire path, minimizing the distance to the targets, and maximizing the size of the targets.

Another way to implement frustrating difficult to use erzatz pie menus that totally miss the point is to only use the small areas of the item labels as targets, not the entire huge wedge shaped pie slices extending out to the screen edge.

Yet another way to screw them up is to trigger them when you move a certain distance from the center (or pop them up when you roll over a target without clicking, or use time-outs without clicking), instead of when you click or release the mouse (or tap or release your finger, pen, etc). There should always be a kinesthetic delimiter like a click or tap at the beginning and ending of the stroke, but the stroke is free wander around any path or pause for any duration. Only the angle between the delimiters matters, to allow for browsing and reselection and error correction.

If distance or time is the trigger, the user has no way of reliably and directly controlling or sensing at which point the selection happens, or using the menus without looking at the screen, and it terribly interferes with navigating nested pie menus.

Any pie menu that does not initially pop up with the cursor (or your finger) in the center, or that is already showing before you start tracking from anywhere on the screen, is terribly broken, because the whole point is to bring the pie menu center to you, so you can select with quick directional gestures without looking at the screen, not for you to have to first look at the screen and then move to the center yourself. That would totally defeat the purpose of pie menus!

Handling the screen edge problem can get tricky, especially when combined with mouse-ahead display suppression. One way of handling that is to "warp" the mouse back to the center of the menu if the menu needs to be moved to fit on the screen. But you must be careful not to cancel out any motion away from the center that's already happened (which is why you should delay warping the mouse until you actually pop up the menu (if ever), so there is no mouse warping when you mouse ahead and the menu is not displayed).

Web browser don't directly support mouse warping (i.e. like XWarpPointer), and you can't tell if the edge of the browser window is actually the edge of the screen, but you can use the "Pointer Lock API" to implement a software cursor that you can warp anywhere in the window you want (but not outside).

https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Loc...

There's a lot more discussion of screen edge handling and mouse-ahead display suppression here:

https://medium.com/@donhopkins/olpc-sugar-pie-menu-discussio...

Also see the discussion of "gesture space" here:

https://medium.com/@donhopkins/gesture-space-842e3cdc7102