Why not the V key? I don't see any reason to retain it for vertex paint mode toggle now that we have a pie menu,also it is one of the lesser used modes, so why should it have a single prominent key, while the others modes don't?

besides the obvious V = view

Edit: the V key seems rather crowded after some looking into it, but there are several tilde combos left - perhaps CTRL + ` would be a good one for the view menu, its a pretty easy reach

About two usermodes and center button - I don't think the 2nd usermode (tap key) should go.

One idea: The user has to clearly decide via options which way to use.
For holdkey-movemouse-releasekey center button would work like described before, for tapkey-movemouse-clickmouse the user needs to click on the center button.
Cancelling would happen by moving far away into dead area (that's for both modes).

What happens if the user acts like he is in mode a but isnt?
a) he accidentally triggers the center button (what is not a problem, if these are designed as toggles, doing the same thing a 2nd time brings him back to start situation)
b) he keeps the key pressed while a single tap would be enough to bring and let it stay open. Can that event be filtered? Not that the menu starts to flicker when keyrepeat kicks in.

A better solution would allow auto-detection of the used mode. I dont have an idea for that right now, if no one comes up, the question is:
What is more important: Benefits of center button or ability to freely switch between user modes?

I don´t think I saw anything about this above, so if I there is don´t shoot me, but if you make the tabkey into a piemenu, how about the option that quickpress without mousemove simply changes between edit and objectmode like before? Going to save you a lot of annoyed users when extended testing begins :P Otherwise I love the implementation, even if I too agree the spacing is a bit far apart.

nevermind about the spacing distance, but I don´t get the irregular spacing :P

@Ted Nielsen (brilliant_ape) There are some bugs with spacing that is known already. Also, at this time there are "blank" spaces where options should be. Such as if you don't have a particle system, the particle edit mode is not shown, so it will be a blank space. I've asked @psi-fi to grey out options instead of hiding them, but there might be some technical difficulties with coding that.

The problem with some menus, such as the object mode menu is that they use enums which do not get managed internally yet. I think the safest here would be to either gray the options - though I am not a big fan of that - or just reserve the positions of the items but use a separator item instead (which just renders blank). That way the user retains the memory positions. Then again, for object menu in particular I don't think it's so bad to have a few items readily available when the object has a few available modes.

What I have found out as well is that for multi key pies it might be good to enforce click style menus because it is awkward to keep the second button pressed.

So far I have added animation and a hold and spawn capability for pie menus. This is used on object mode and view menus already.

I tested the drag timeout value.
It seems to be counter-intuitive.

You will choose a click style menu to take your time while hesitating between items, checking many items of a dense menu.
So to take your time, you have to be quick and release button before drag timeout value and after operator timeout value.

I think that it would be more intuitive to change to click style after pressing key during a certain time.
This default value could be set to 1000 to disable this behaviour by default.

I forgot to tell that, imho, radius should be value specific to each pie menu.
It would be great to be able to tweak things like this in input section of preferences.

Having per-menu radius woudln't be bad indeed. The operators with timeout require you to hold the key already so I was thinking of forcing those pies to be hold style. Seeing how you consider this to be counter-intuitive maybe we could provide an option. Actually I'm not even sure if having a drag timeout is convenient. People will prefer one or the other usually (click or drag). For some cases like the one I mentioned above, we could hijack the user preference and force one over the other.

Sounds good - forcing click style for certain menu's (like Q key sculpt experiments) would be quite beneficial.

@ronan ducluzeau (zeauro) - Curious to know where you would expose in the UI per-menu radius? Is it really needed since pies are limited to 8 slots?

I'm sorta curious about the options as well. Currently there are 3 different options that all relate to how button's 'feel' when calling the pies, and they sort of step on each other toes. Curious if this could maybe be simplified.

Drag Timeout: Really either needs a different description to explain exactly how this is working.
Operator Timeout: Easy enough
Recenter Timeout: Could perhaps use drag timeout value?
Radius: Easy to comprehend
Threshold: Could use better description, but easy to understand

"forcing click style for certain menu's (like Q key sculpt experiments) would be quite beneficial."
I agree that for a menu with sliders and buttons; it could be useful.
But for the same reason that it is beneficial to be in hold style for entering a mode or enabling/disabling a single option; I think that menus mixing both types of items should be avoïded.

"@ronan ducluzeau (zeauro) - Curious to know where you would expose in the UI per-menu radius?"
I was not enough precise. I mean in keymap configuration.
Apparently a pie menu would be carecterized by keymap to call it.
Lots of operators have preferences that can be defined under their shortcut.

I think that it would be consistent.

I was told to paste this here:

tapping "o" = toggle Proportional Editing ON/OFF (as it is already)
holding "o" = Pie Menu appears with all proportional editing options

tapping "e" = extrude region (as it is already)
holding "e" = Pie Menu appears with Extrude options (Region or Individual)

tapping "o" = toggle Proportional Editing ON/OFF (as it is already)
holding "o" = Pie Menu appears with all proportional editing options

Also I'd like to add that I think the current Proportional Editing interface is not well done.

Here is a mini-proposal on how it could be done better - link.

tapping "z"=toggle wire/solid mode
holding "z"=pie for all shading modes

tapping "b"=box select
holding "b"=Pie to activate other selection modes

I bet there is an infinite amount of these!

Didn't read whole topic... Have you guys consider SUB-pie-menus? Or in other words pie menu that invoke another pie menu? Nothing new in fact, will be great if blender have pie menus like that. This can be awesome time saver. Basically under one key (Q) we can have most of dropdown menus from 3Dview like interaction mode, pivot point, snap element etc.

How to do that? Draw thick line on radius (this setting in user preferences). When user move mouse beyond this ring normal operations or invoking another pie menu are executed instantly.

If user don't reach ring and instead release key before- normal operations are executed as above (just like now) but if user was pointing item that should invoke another pie menu this next menu is automatically set to Click mode (because no key is pressed).

Mode pie menu are related to current interaction mode. For example Face/verts/edges menus in Edit Mode or that what Sculpting Mode have now under Q.

In areas where there is no options to select or areas with nested interface items user can move mouse freely. Ring is not drawn here, we can move cursor beyond it in that specific section of pie menu.

I'm sure after a while people will select things in first pie menu (Q) instantly without reading. This can be super efficient. What you think about it guys?

I would just change the RMB to pie menus instead of 3D cursor. It is more used then it. Alt + RMB could work for 3D Cursor instead or even Q :).

You mean LMB. This button do many other actions, not only position 3d cursor. Moving manipulators also use it, it stands for action confirmation and is used in menus or even clicking in options in pie menus and because of that user can be confused. Basically in other programs one thing invoke menus and other (LMB) gives you ability to select desired option. Same key for both will be a strange solution. Imho this will be too much things and actions for just one mouse button.

@Bartosz Moniewski (monio) He is talking about RMB after switching to LMB select - which is correct, because we are going in this way.

@Vlad Mafteiu Scai (00Ghz) After having cursor placement on Alt-RMB for a while now (and a context menu on RMB) I'm starting to think that a Cursor Placement Tool could be a better solution.

Workflow Example - You click on the Cursor Placement Tool's button, click with LMB in the viewport to place the cursor (this does not exit the tool mode, so you can for instance rotate view and click again), and when you are satisfied with the new cursor placement you press RMB to exit the tool mode.

Monio: IMO inner cirrcle is too small, it could do unwanted selections especialy in submenu if you move mouse too far.
Outer circle should not overlap with menus, people should freely go over and out on menu items.
last two image is too inconsitent for me, i wouldn't put options like this to pie menus.
Sub pie menus looks like good idea but I think it shouldn't be nested more than one or two menus down.
Another thing is how to back to previous pie, probably inner circle click.

Not sure, seems to be slower then usual using a tool but the 3D cursor isn't used that often anyway so it might work.

Besides the most times I do need the 3D cursor I have some custom shortcuts we might consider besides of a general Shift + S menu.

So I have:

Ctrl + ` for Cursor to Selection
Shift + ` for Selection to Cursor
Ctrl + Shift + ` for Cursor to Grid

Now in the rare ocasions where you need the 3D Cursor for tools like screw/revolve etc I would rather use a 3D View manipulator anyway because it provides live feedback instead of just:

1. Click to set 3DC, use screw tool. If it doesn't work:
2. Set 3DC again use tool again.
3. And so on until you get it right.

Also the 3D tool doesn't have a normal axis. So it can't be used as a Modo work plane to place stuff oriented on a poly normal. But that's another topic altogether.

Let's keep it focused please, modal popups are for another task entirely.

The idea about linked pie menus is nice - not sure if I like to drag to the edges of the menu though since it requires bit movements - of course we can have a custom threshold - again - here.

For a first implementation though I may not have time to do this. Pie menus have already taken too much time and tasks that seem little and innocuous can take up considerable time to research.

Also people requested items in a sidebar. I don't know how well those will play with multiple levels of pie menus. Code wise it will be easier to handle without the sidebar of course, handling two intersection modes, direction and 'hit' based in one block is bound to get a little messy. We could do both of course but supposing a user starts dragging towards the sidebar across multiple pie levels this can get troublesome fast.

Generally sidebars seem to me as too much complication just to fit in more and more stuff for the user to see and without considering the benefits of the pie interaction model. Sidebars are what the T panel already is. Maybe what we need is just a key based way to toggle the context in that panel instead?

First implementation plan is for single level menus.
Current pie menus focus on selecting between properties for one operator or choose a value for a context variable or tied to one context operation. Those are well suited for one pie.
You could say that multi level pies and sidebars try to solve uniting such sub operations together. So I don't think solving the simple problem now conflicts with the second.

Since we are talking 3D cursor here, I have a few ideas there:

, key: spawn pivot pie
. key: spawn cursor placement pie.

Cursor placement through mouse becomes a modal operation instead - start, press to confirm - and we can even have options such as limiting to middle of the mesh volume by depth peeling or similar...those are ideas for later :)

@Paweł Łyczkowski (plyczkowski) - So people here agreed to switch to LMB selection model? I'm fine with that, maybe I also switch my workflow to it. Which blender release will have that? Can you show me task for this? Just send me a link, we don't want to raise discussion on that here. Cursor placement tool (with hothey of course) will be nice. I often move my cursor unintentionally and must set it back by SHIFT+S menu. I suggest you to start a design task.

@Antonis Ryakiotakis (psy-fi) - I also think that sidebar and menus with multiple items are to complicated for pies. Symmetry options in Sculpt Pie look nice but they are already complicated a bit. I cannot imagine having whole Specials menu nested in Pie menu. On fact blender already have "sidebars" menus with buttons- Specials, Edge/Vert/Face, Add... They can have sliders, check-boxes, values (look at cell fracture addon). All things cane be done in python, question is what users really want to have as standard popup menus. And this question is beyond this task obviously. ;)

@Bartosz Moniewski (monio) Yeah, Jonathan is for it, as well as me, Andrew and William, so we have a pretty good consensus. Some (incomplete) propositions can be found here, as well as in the work done by Nathan Vegdahl. Here is the design task - https://developer.blender.org/T37420

As a french linux user, I have to say that it would be cool to forget "." keymap.
On an azerty keyboard, it is accessible by pressing it with shift. It is the same keymap than ";" .
Would it be a drama to use ; instead of . during tests ?

I don't know if there is an UI task about qwerty/azerty remapping tool for keymap config.
http://fr.wikipedia.org/wiki/AZERTY#mediaviewer/Fichier:Clavier-Azerty.svg
http://fr.wikipedia.org/wiki/QWERTY#mediaviewer/Fichier:KB_USA-standard.svg

@ronan ducluzeau (zeauro): I think that falls out of scope of this task too - should probably be in the keybindings thread or a new task altogether.

@Bartosz Moniewski (monio): I like your mockups. Not sure about all the interactions - some might be a bit too 'fickle'. I have played with pies that call other pies in the addon, but ran into some bugs with the interaction mode and getting multiple click events sent. It probably could be investigated further after first implementation is done.

@Antonis Ryakiotakis (psy-fi) on 3d cursor: Cool on menu. I get sneaking suspicion that changing 3d cursor interaction that drastically might come with strong turbulence. Put on your chain mail armor now :-)

On side menus: I would like to keep the pies limited to items that are changed frequently. The question you should ask yourself is, "Do you change this setting on an order of once every 2-3 minutes? (When working in that particular area)" If not, it probably is fine in the side bar and should not be in a pie menu. If you are changing it all the time, ie. In sculpt "Strength, Size, Mapping, Stroke, Symmetry" or the Brush then it should be a popup on the mouse.

@Paweł Łyczkowski (plyczkowski), after switching to LMB select - which is correct, because we are going in this way.

Any links to this topic? - First I heard of it,

He already posted links.

@Campbell Barton (campbellbarton) "We are going this way" was a bit strongly worded. Brecht put it better:

I think there is some agreement that we will make left click select the default, Ton agreed with it as well as long as we have a well supported way of switching to right click select.

https://developer.blender.org/T37420

Note, the underlined key accelerators aren't currently supported by pie-menus.

(The letters are underlined but pressing them on the keyboard does nothing)

I've been pondering what to do with the 'Q' key view menu...where to put it.

What about on "space" Tap space brings up the search operator thing, like currently. Hold space brings up the view pie. Unless we want to save this for some sort of "super pie" like the "dynamic spacebar menu"

Bug: Bounding Box & Material draw types are missing on 'Z' key pie when in Blender Render...Can't check others since I can't compile cycles for some reason.

I think most things are complete here:

List of pie menus so far:

Viewport
TAB (sticky): Interaction Mode
Z (sticky) : Shade + solid vs smooth shading
Q : View directions + perspective/ortho and camera
Comma (sticky) : Snapping
Period (Sticky) : Pivot
Ctrl + Space (Sticky) : Maipulator

Edit Mode
E (sticky) : Extrude options
O (Sticky) : proportional editing
Ctrl + Tab : Selection Mode

Paint Modes:
E : Strokes

What might be nice here is a way to explicitly request a certain slot, but this is no simpe change. It either requires to overload each prop etc layout method to accept a pie slot, or add new layout items that represent those slots. It's not completely out of the question, yet I don't know if it's doable for this release at this point.

The interest of pie is to replace lists menus, to be more efficient at work with an item that can be reached quicker.
But for a first step, everybody agrees that without ability for subpies long list like specials menus are not good candidates.

I think that shift ctrl alt shift C menu for origin is a good candidate. It is revealing that people want also pie-menus as an alternative to tricky shortcut.
We are facing a problem all keymaps are not good candidate for sticky menus. Q was an unused key until today. I think it is a mistake to use it as a single keymap.
It could be used as a modifier keymap for pie-menus.

Q Spacebar could be for view navigation.
Q C could be for origin menu.
Q S could be used for snap menu (Selection to Grid,...Cursor to Active).
Q E could be used for Sort Mesh Elements.
Q T ... for Transform other than GRS (To Sphere, Shear, Bend, Push/Pull, Warp, Randomize, Shrink Fatten)
Q F .... for Quick Effects.
Q G ... for Game Properties.

I think that it could be cool way to remind that blender have this feature to use any key as a modifier for shortcuts.
It is an understimated feature. I don't know what is the status of new keymap configuration.
But if P was freed of its function to launch game engine, It could be a great modifier for right side of keyboard.
So, P O could be used for proportionnal editing Falloff type.

That's a good mnemonic rule but in my experience double keys are really awkward for pie menus, especially pie menus of drag style. Also I think the sticky style is really pleasant to use. In any case we can re-discuss when we rethink the default keymaps.

I agree brain have difficulties to press 2 keymaps and move mouse in one direction at same time.
I am just a little bit worried about the use of the last unused key.
It makes the need to rethink default keymaps more urgent for future features.

Note: Pie-menus don't currently scale well with DPI.

For example, If you set DPI to 144

Hold tab and the header for the menu is obscured by the buttons.

Note on usability.

Without Pie-Menus (2.71 release), You can do this in editmode for example.

• Ctrl+Tab,1 (to switch to vertex edit mode, 2, 3 for edge and face)

With the new piemenus you can't do this anymore.

I think this shouldn't be overlooked, when modeling its an extremely common operation,

For this to work I think that number button accelerators would have to be supported by pie menus (which isn't a big deal), But they would also need to stay open to give you time to press them.

Interested in feedback on this topic, We could also not use pie menus for small menus, but think its worth trying to support this, or we should at least have to have a good reason not to.

@psi-fi - let me know what you think, I can check on this if it helps.

agree that mesh select mode feels a bit slower... combos like edges+verts could be added here btw, it looks too empty :p
and maybe click mode should be default? easier for new users and for shortcut keys -also numbers as default is not bad-

The reason why I haven't added support for numbers - though supporting is really easy, just like letter accelerators - is that there is no intuitive mapping for pie menus. You could do the mapping in the order they are added to the pie, but then this is not so intuitive. An alternative is to just use clockwise or counterclockwise order. This can also be done but then after a new item is inserted the numbering becomes invalid. Then again I think that the whole notion of pies is to be gesture driven. If users are used to the spawn + number workflow then it might be better to just use old menu for selection modes.

Yeah, I agree that combos can be added on that menu if we keep it. Also we can have click mode by default and reduce the animation time too to make them feel faster.

After discussion with Campbell we will use combination of drag-click style. If user releases the button while still within the threshold, the pie becomes click style. I feel this is the best solution by far, less options and allows both click and drag style proponents to use the menus intuitively.

Also reverted the selection mode menu unless we agree on compatible numbering scheme here.
I'm fine either way (popup vs pie) for selection modes.

@Antonis Ryakiotakis (psy-fi) the pie-menu is currently clamped by the editor area. If the view3d is too small you don't get to see the entire menu. The ideal would be to do like the 'Search Menu' (space bar). Looking forward for the complete documentation and nested menus, so far this is what I'm using the pie-menus for (multiview display mode) - P108

I just tested this here but I feel like pie menus are too "invading" to other editors due to their spread out panel-less nature and it's better to clamp them by editor area.

I did the change after all, remains to be seen if we keep this.

After tackling the last issue with numberpad selection, I have added a patch for review:

https://developer.blender.org/D692

Hey @Antonis Ryakiotakis (psy-fi)

Sorry for taking so long to review this.

Numbering is off for pies
Pies numbering seems to be off. For example, with mode switching (TAB), there's 1, 4, 6, 7, 8, 9. But no 2, 3, or 5?

I realize this is due to the pie slice locations, but it does feel quite odd. I'm not so sure that the location association is better than sequential.

Is location numbering used in other apps?

Selecting Pie Slice with Number
When selecting a pie slice with the number keys it'd be nice to see some kind of animated confirmation to communicate to the user that their option was actually selected.

Simply highlighting the pie and then fading quickly would work well. Similar to how it works when clicking on a slice.

Beyond that everything looks good to me. It's really nice and polished and the default pies look really good for now.

I don't see anything else amiss. And even those two things are very small (even nothing perhaps).

Also thanks for putting in the pie menu python template. I'll most definitely be adapting some of my stuff to pies!

it is not a sequencial menu but a radial one, I think numpad numbers makes a lot of sense and will remain the same for 3 items or 8...
maybe add proportional editing menu to object mode too, and combos to manipulator menu? nice work!

In T40587#100, @lower case (lowercase) wrote:

it is not a sequencial menu but a radial one, I think numpad numbers makes a lot of sense and will remain the same for 3 items or 8...
maybe add proportional editing menu to object mode too, and combos to manipulator menu? nice work!

Ah of course, I should have caught that. I don't use a keyboard with a numpad, so I didn't den think about that.

Yes, the idea is to have consistent numbering here rather than fill all numbers.

Consistent means that when you try to select an option that is not present due to context, other options are not shifted to take its place so positions stay the same. Same with numbers. Each number is tied to a direction based on number pad.

If that feels weird we can consider separating the scheme and using clockwise direction (or other numbering scheme) with regular number keys (always counting empty positions too for consistency) and for numberpad keys don't use the actual numbers but the direction when taken from the center.

I would vote to bring ctrl+tab pie in edit back. I agree, it breaks muscle memory, but this one is really the ideal candidate for pies. And with pies set to drag it is just or at least almost as fast. Especially if we extend the menu to combinations of the modes, vert+edge, edge+face etc.

I too miss the ctrl+tab with the combo modes. It's nice to hear that I'm not alone on this. I don't feel it's a reason to delay incorporation of the general pies though. In fact we could probably start a new design task once pies are in to discuss incorporation of further pies.

Hi, I will update this thread with info from the latest discussions during dev meetings.

Looks like sticky keys cannot be accepted in blender because they create a new interaction paradigm that was not really discussed and designed for. This is not too terrible in itself but there had been objections from other developers on including this.

Also due to the nature of UI (everyone has his own idea of what works and what doesn't) we decided to ship just a few pie menus as an official add-on that defines them and overrides some operator keymaps with them. This way users will be able to turn them on and off and add-on writers will be able to write their own, taking the official add-on code as a starting point.

For the official add-on we will probably do an object mode pie, a view pie and a edit selection mode pie for starters. Not too loaded. The idea is to see how people will use this and possibly make it easier for others to make and customize their own pies, as time goes by.

That's bad news. The sticky key interaction mode is a really useful functionality. What are the objections?

The objection is that it creates an expectation that operators will work as tap - execute, hold - spawn properties pie everywhere.
It may also conflict with the modifier key design somewhat, which works by holding a key down and clicking (grease pencil is an example here).

A personal objection is that the way it works in the code currently is, admittedly, somewhat hacky. Sticky keys applied only to pies and can't be generalized, like for instance hold a key to do something else than spawn a pie. That is not such a big issue though and I would be willing to accept this as WIP if others did.

First: great work guys!

My only concern is about view menu: why is not present Frame Selection? It was in previous pie menu. IMO is most useful than ortho/perspective view.

Also, any chance to see a tutorial to how customize or even create our piemenu?

Thanks again!

it creates an expectation that operators will work as tap - execute, hold - spawn properties pie everywhere

Well, this expectation would be met, and some keys would provide additional options when held in the form of the pie menus, or draw mode for grease pencil.

About the hacky approach - I guess that the way the d key works for grease pencil is also hacky currently. So - my opinion is that it would be beneficial to implement the "hold" functionality as a genuine keymap option, that can be used potentially for pie menus, for grease pencil drawing, and other functionalities.

@Paweł Łyczkowski (plyczkowski) & psy-fi - I admit that I am going to miss the hold functionality. At least the pies branch can be seen as a proof of concept that it work, and that it works well. But I do agree that it should probably be rolled into the keymaps as a fully supported option. This is going to take a bit of design work in the keymap area as well and perhaps should warrant a new design task.

Just to add, the only issue I see with Q is that IF we approach the QWER convention for transform, scale and rotate, the Q is generally reserved for hiding the widget altogether. If theres a desire to keep it as usable as possible going in, preserving that habit/convention might be beneficial. In order to have both, the hold functionality is def important... in that case it could be press and hold = pie menu, tap and it drops the transform/rotate/scale widget.

Can anyone tell me the difference between a regular hotkey and a 'sticky key', how would sticky keys allow for a good workflow with pies vs. just pressing the key and having the pie come up?

I think in a sense, we should at least have...

-An E-key pie with the extrude tools
-An F-key pie with the fill tools
-A pie with the merge and rip tools
-A pie with the dissolve and collapse tools
-A pie with the knife, connect vertices, and knife-project tools
-A pie with the transform tools (including edge/vertex slide and shear).
-And a pie with various advanced tools (shrink/flatten, bridge, bisect, inset, ect...).

It would save hotkeys and still allow a fast workflow along with increasing tool discoverability (while allowing them to still execute where the selection is). Is this still targeted for 2.72 by the way, it would be a bummer if it wasn't?

Everyone has their own ideas of what menus and shorcuts should be used, so I think Ton's idea was the best after all, we can't hope to satisfy everyone.

To summarize (again, will also put in task description):

• We drop sticky keys (I can show how to code a sticky operator in the pie add-on though ;) )
• We ship official pie add-on with only a few pies defined (object mode/view shade mode/probably edit selection mode) and leave any others to scripters.
• Blender side we try to make life of scripters easier. Ideally I would love to design pie ovens too but they are a tough nut. It may take a while, so no promises there yet. I will surely get inspiration from add-on writers on that.

This means a few things:

• People start bothering add-on writers/themselves about pies and shortcuts instead of me (happiness! :))
• Add On writers start bothering me when a pie does not work well.

Waiting on final review and will commit shortly.

Will pie menus become default option in blender someday? I think burying features in disabled addons is worst thing in terms of marketing purposes. One can say blender can have any feature written as addon but for new users only things that works out of the box matters. This will be hard to convince them to visit blender artist forum, download some python script, install it, try to remember that tutorials they watch use same keys to enable different things depending on addon they choose (pies vs other pies vs menus)....
I assume only few percent of experienced users will ever try to use this and rest will stick to defaults.
I hope pie menus will become default option in near future. Otherwise this will be wasted potential.

@DataDay (DataDay), removed your last comment.

You can express your opinion without being offensive.

@Adam Friesen (ace_dragon)
sticky key = press and hold a key for a set amount of time to spawn menu.
regular hotkey = tap a key to hold do something or spawn a menu

The point is that with sticky keys you can do more with one key. Example "Tap tab to switch beteen object/edit mode, hold tab to bring up pie menu of all modes"

@ everybody else
On sticky's and Ton - I think he was not opposed in general, but wants a more robust implementation, and does not want them used in a default keymap. I think this is a different battle that should be fought by the UI Team if they feel it's an important task to pursue. Including sticky's in keymap editor would be nice, but will need design work. Maybe @Paweł Łyczkowski (plyczkowski) can think on this?

Maybe @Paweł Łyczkowski (plyczkowski) can think on this?

Well, the best solution from the design standpoint would be just to add "Hold" option here:

But I guess it's not that simple - different operators would have to react differently to a held key. For instance the grease pencil draw would have to end the operation when the key is released - the pie menu would not (at least when the mouse cursor would be still in the middle), etc. A dev would have to comment here, I have no idea if this is feasible code-wise.

Campbell, It wasn't offensive unless you get offended by sarcasm with an intended message.. I explained that the sarcasm was used with, and I quote "the intent of hitting on a sore point a lot of people feel". Perception matters, even on the development end I would say. Regardless, this is not the place to argue or debate semantics or perceived offenses.

From the previous post:
Like Monio, I do have concerns with the Pie Menus being written off as an "official" plugin, especially if its outside of the core of Blender's core design. Starting to sound more like a last minute "toss the baby out with the bathwater" move. If thats not the case, I hope there can be some action to show its not the case otherwise its just business as usual.

Pie menus hit on a key part of how you can design and interact with a piece of software, if its just left as a "minimal addon" for people to code their own aspects on top of it depending on their fancy, then it doesnt really address one of the perks of having a UI with a built in pie menu workflow.

Anyways thats just my 2 cents on the recent development to turn an add-on into another add-on. I am sure new users will enjoy being forced to make their own pie menus in the future.

This won't work well with modifier keys, that's why original design was to use a "sticky operator" for that.

I'd say a sticky, or "conditional" operator that acts based on a timer condition, would be nice here but in a way that allows users to configure the operators that will be spawned, as well as their options.

@DataDay (DataDay), maybe offended is wrong word, just keep it civil, avoid being snarky.

This won't work well with modifier keys, that's why original design was to use a "sticky operator" for that.

How about disabling modifier keys when the "Hold" functionality is used? This would be made clear to the user with the modifier keys checkboxes being grayed out.

Campbell, to be honest, the decision by Ton seems to be threatening to start yet another riot against him on BA, so I think we should have a good selection of pies (for object, edit, and sculpt mode) at least in 2.72 (even if they're in the form of addons that are shipped with Blender). Otherwise, it's possible that this and other instances could pose serious implications for the future development and funding of the Blender project.

Come to think of it, perhaps we really should have multiple addons that add pie menus, so you could have as many or as few pies as you want without needing to learn Python. That might be a good way to please users. In addition, we really should eventually bring the sticky keys back as something fully supported in the hotkey editor (and available for use with Python for things like spawning pies).

In all, I think the major sticking point is that some remember Ton saying that he is powerless when it comes to what people want to develop, yet it seems like what features come in under what form is exactly dependent on his final say. Of course I know that Ton himself was interested in Pie Menus in some form, but there's a growing school of thought that gives the impression that Blender is for Ton and not for anyone who wants quality free software.

Hello guys!

I have some request about super cool Pies:

• Add orientations (Alt+Space) to pie menues. As they are mostly usable in modeling/objectPlacement
• Add shortcut for pieSnapping (Ctrl+Shift+Tab). Right now it's in "," shortcut. But original shortcut is "Ctrl+Shift+Tab".

Thanks.

I'm not necessarily tied to ", " for pie snapping, and would not be opposed to it changing, I am opposed to shortcuts like ctrl+shift+tab though. Anything that requires 3 keys to activate should be rethought. I do think this discussion in misplaced in pies though, and should probable be in the keybindings discussion here: https://developer.blender.org/T37417

Additionally, steps should be taken before we tackle that huge task as well, and that is getting the inclusion of sticky keys in, as well as the ability to modify double tap keys (like gg for edge/vert slide/ or rr for changing rotation method). Once those tools are in, we can go after a new keybind setup. Until those are in, it does not make sense to start changing binds around.

As far as orientation pies go, it could definatly be made, but I personally sorta want to roll it into the widget pie with a hybrid pie - having a drop down menu to select orientation on the south spot of the pie.

Shift+Tab - Snapping.
Ctrl+Shift+Tab - Snapping modes.
And all people use Ctrl+Shift+Tab as it's faster for the left hand.

@Antonis Ryakiotakis (psy-fi), think we can close this? If we need to do more design discussion might be better to do that in a separate task, this one got quite messy.