Is this task meant for improvements in general to the pie menu, or just these specific proposed changes?

KiJeon: What do you mean?

Small suggestion in regards to the pivot point pie menu. I think the two most used pivot point settings are "median point" (the default one) and "3d cursor" so it would make things faster if they were on opposing sides, and "active element" is, I think, much more often used than "bounding box center", so it would be nice if it was placed on one of the main directions, opposing "individual origins".

Pie menu active state was fixed by commit: c234c3db1bcb

@William Reynish (billreynish), could you report an issue for remaining Pie menu glitches?

@William Reynish (billreynish) I mean is this task open to discussions on how to improve the pie menu in general, or meant only to discuss the specific items you outlined in the Description above?

I ask because the title seems to indicate the former, but if the intent is latter, I don't want to add noise to the discussion.

Campbell: You are right. Will do.

KiJeon: You are welcome to suggest or point out something that could work better or differently.

However, the numbering order is scrambled. It doesn't follow the order of the actual items, which is left=1, right=2, top=3, bottom=4, and so on.

It's not scrambled, the layout follows that of the numpad if I'm not mistaken?

Stig: You are right. Removed this section.

Fix for: Holding, Then Releasing Key Should Always Dismiss Pie
I believe this fix complies with the intended behaviour of the pie menu as per the discussion at devtalk

I'm attaching a diff that adds a "Tap Key Timeout" setting to the Pie Menu preferences. It changes these files:

release/scripts/startup/bl_ui/space_userpref.py
source/blender/blenloader/ versioning_userdef.c
source/blender/editors/interface/interface_handlers.c
source/blender/makesdna/DNA_userdef_types.h
source/blender/makesrna/intern/rna_userdef.c

OR Instead of the diff... try it out with a hardcoded value of 20 by changing one line in interface_handlers.c:

+++ b/source/blender/editors/interface/interface_handlers.c
@@ -9405,7 +9405,7 @@ static int ui_pie_handler(bContext *C, const wmEvent *event, uiPopupBlockHandle
                        }
                        else {
                                /* distance from initial point */
-                               if (!(block->pie_data.flags & UI_PIE_DRAG_STYLE)) {
+                               if ((duration < 0.01 * 20  ) && !(block->pie_data.flags & UI_PIE_DRAG_STYLE)) {
                                        block->pie_data.flags |= UI_PIE_CLICK_STYLE;
                                }
                                else {

I submitted a proper diff here:
https://developer.blender.org/D4180

Sorry for all the noise.. learning the system.

D4220: Action With Second Press of Pie Shortcut Key
I've been trying out another change and have made a patch here

My first experience with Pie menus I expected to be able to toggle them away with the same key I used to bring them up and was slightly annoyed when that didn't occur. This patch also allows you to activate items with this key ( after a mouse move ). Essentially it acts as a mouse click.

I also felt ( not so strongly) that pressing the middle '5' key on the numeric keypad should act as if you clicked in the middle... i.e. dismiss it.
I expect a reviewer to request this be separated out into a second patch but have left it in for testing.

Issues:
If the pie is called up with a letter and no modifier then you will not be able to access a shortcut in the menu using that letter. This isn't an issue for modified key codes such as Shift-S. If it's a concern a preferences setting could allow the user to disable this or maybe change the shortcut to a shifted version.

Default Pie Menu Action.
Also... I'm experimenting on ways to allow the short 'tap' of a pie-menu key to perform an action ( instead of sticking the pie menu ).
For example, z held down brings up the Shading Pie menu however tapping it would simply toggle wireframe mode.

With the patch in my last post ( action with second press of pie shortcut key ) you can assign a double-click key action to a pie-menu key and have it occur when you activate and dismiss a pie menu with two quick taps. A preferences setting could modify this so that the double press action occurs for pie menus when a single short tap occurs.

Complex Pie Menus for testing?
Are there any test pie menus hidden away... something involving pie menus with inner block menus/pie menus etc?

D4220: Action With Second Press of Pie Shortcut Key

That seems reasonable. The conflict with shortcuts for items I guess can be avoided by consider that key as already taken so it users a different one.

Default Pie Menu Action.
Also... I'm experimenting on ways to allow the short 'tap' of a pie-menu key to perform an action ( instead of sticking the pie menu ).
For example, z held down brings up the Shading Pie menu however tapping it would simply toggle wireframe mode.

We tried this for tab and edit mode switching, but found it does not work well. Many users multitask and move their mouse while pressing shortcut keys, and so accidentally trigger the pie menu.

Complex Pie Menus for testing?
Are there any test pie menus hidden away... something involving pie menus with inner block menus/pie menus etc?

Not that I'm aware, maybe @Julian Eisel (Severin) knows.

In T56949#601428, @Justin Jones (jjones780) wrote:

Complex Pie Menus for testing?
Are there any test pie menus hidden away... something involving pie menus with inner block menus/pie menus etc?

I can answer this. There aren't any 'complex' pie menus in the default Blender pie menus. We decided against this for now, as they go against the main advantage of pie menus, which is the speedy, gestural input.

However, I believe there are some more advanced ones inside the pie menus addon, and there's also the Pie Menu Editor addon that allows users to build very complicated custom things.

I cleaned up my original diff and added an Interface->Pie Menus preferences entry "Pie Key Again Click" - "Pressing pie shortcut again will act as click ( to cancel or select )" which defaults to enabled.

Still diff D4220

I tried it with some of the pie menu add-ons: works well with submenus.

Is there currently a way to re-arrange the Pie-Menus from the side of the user?
For instance the horizontal axis for the most used items is completely wrong for me, and I'd like to have them on a vertical one - so for instance the a TAB pie menu would have Object mode up top and Edit mode on the bottom.
Or at least provide us with a settings option to change them from a horizontal layout for most used items to a vertical one.

I like the tab pie menu but I'm one of the people who move their mouse a lot when pressing tab - so I constantly go into vertex paint when I just want to exit from Edit mode to Object mode with a single tab press.
Increasing the time needed to hold the tab before we can move the mouse to enter a pie menu would be cool too.

I hope I'm not putting this in the wrong place. But I have a feature suggestion for pie menu.

It could be helpful if pie menu had sub-pie menus. For example a default sculpt brush could be the main selection, but the same brush with modifications could be a sub-pie menu.

Or, in general for say properties window. Sub-pie menus could descend into setting those properties, where finally the relevant setting widget would pop-up in the pie menu and be ready for manipulation by the activating device. dyntopo properties would be a breeze with this kind of set-up.

This type of set-up would create the fastest way to manipulate widgets, because it uses the least amount of pixel real estate to make those changes. It would be second place for speed to a hotkey.

Sorry but I want to swap where edit mode and object mode are but I don't know how.

If you do respond thanks in advance.