Pie Menu Hotkey Customization #110496

New Issue

alegator-rotagela · 2023-07-26T15:38:06+02:00

alegator-rotagela commented

2023-07-26 15:38:06 +02:00

Summary

As a blender user, I am interested in customizing the hotkeys for pie menus. If properties with key press events can be added to a layout, then it follows that operators with key press events should be possible to be add to a layout as well. This applies to pie menus, but also to the items in any layout.

Current

# 4 - LEFT
pie.operator(...)
# 6 - RIGHT
pie.operator(...)
# 2 - BOTTOM
pie.operator(...)
# 8 - TOP
pie.operator(...)
...

Desired

pie.operator(..., key = 'l')
pie.operator(..., key = 'r')
pie.operator(..., key = 't')
pie.operator(..., key = 'd')
...

Intro

New to blender source code, been trying to interact on blender discord and blender developer chat for a few days. Trying here now.

Motivation

In principle, pie menus are like interactive modal hotkeys, similar to vim. New users can open a pie menu to see what functionality is relevant in a given context, and experienced users can press a key to open the pie and a second key to choose the operator. Modal pies are to modeling what tab completion is to coding.

Current State

The numpad keys 2,4,6,8 activate the items in a pie menu, and I'm struggling to figure out how I might be able to customize those hotkeys for each pie menu. If there is a way, I missed it.

Desired State

Each operator added to a pie layout can be configured to have a specific hotkey.

So Far

The UILayout class has a .operator() method which could be modified to accept a hotkey to trigger the operator while the pie is active.

There is also a .prop() method which accepts a param event (boolean, (optional)) – Use button to input key events. If properties with key press events can be added to a layout, then it should be straightforward that operators with key events can be added to a layout.

I haven't been able to find the source code for the UILayout python class (the UILayout_Fake class inherits UILayout):

, but there is a section of source/blender/makesrna/internal/rna_ui.cc that might be defining the class jointly for C++ and python.

I also can't find the .menu_pie() implementation anywhere:

To Do

Find the UILayout class implementation
Find the menu_pie function implementation

Relevant Links

Here is an example of typical pie menu code: https://github.com/oRazeD/PieMenusPlus/blob/master/ui.py
Here is some discussion of hacking modal hotkeys into blender addons: https://devtalk.blender.org/t/modal-addon-keymaps/17444/2

# Summary As a blender user, I am interested in customizing the hotkeys for pie menus. If properties with key press events can be added to a layout, then it follows that operators with key press events should be possible to be add to a layout as well. This applies to pie menus, but also to the items in any layout. ## Current ```python # 4 - LEFT pie.operator(...) # 6 - RIGHT pie.operator(...) # 2 - BOTTOM pie.operator(...) # 8 - TOP pie.operator(...) ... ``` ![image](/attachments/2c79b4cf-0c9b-414e-9dd9-5a74dbca30f7) ## Desired ```python pie.operator(..., key = 'l') pie.operator(..., key = 'r') pie.operator(..., key = 't') pie.operator(..., key = 'd') ... ``` ![image](/attachments/e38e7b5f-2af2-4922-b9bb-b11ca68970ec) # Intro New to blender source code, been trying to interact on blender discord and blender developer chat for a few days. Trying here now. # Motivation In principle, pie menus are like interactive modal hotkeys, similar to vim. New users can open a pie menu to see what functionality is relevant in a given context, and experienced users can press a key to open the pie and a second key to choose the operator. Modal pies are to modeling what tab completion is to coding. # Current State The numpad keys 2,4,6,8 activate the items in a pie menu, and I'm struggling to figure out how I might be able to customize those hotkeys for each pie menu. If there is a way, I missed it. # Desired State Each operator added to a pie layout can be configured to have a specific hotkey. # So Far The [UILayout class](https://docs.blender.org/api/current/bpy.types.UILayout.html) has a `.operator()` method which could be modified to accept a hotkey to trigger the operator while the pie is active. There is also a `.prop()` method which accepts a param `event (boolean, (optional)) – Use button to input key events`. If properties with key press events can be added to a layout, then it should be straightforward that operators with key events can be added to a layout. I haven't been able to find the source code for the UILayout python class (the UILayout_Fake class inherits UILayout): ![image](/attachments/0185578c-7380-4a83-a180-1de946d0e018) , but there is a section of `source/blender/makesrna/internal/rna_ui.cc` that might be defining the class jointly for C++ and python. I also can't find the `.menu_pie()` implementation anywhere: ![image](/attachments/a885678a-3e3b-448b-8313-96cc8bd8dd2a) # To Do 1. Find the UILayout class implementation 2. Find the menu_pie function implementation # Relevant Links Here is an example of typical pie menu code: https://github.com/oRazeD/PieMenusPlus/blob/master/ui.py Here is some discussion of hacking modal hotkeys into blender addons: https://devtalk.blender.org/t/modal-addon-keymaps/17444/2

image.png

330 KiB

image.png

330 KiB

image.png

13 KiB

image.png

3.7 KiB

alegator-rotagela added the

Type

To Do

label 2023-07-26 15:38:06 +02:00

Iliya Katushenock added this to the User Interface project 2023-07-26 15:53:39 +02:00

Iliya Katushenock added the

Module

Python API

label 2023-07-26 15:53:51 +02:00

alegator-rotagela commented

2023-07-26 18:40:55 +02:00

Followup

The implementation for the UILayout class is split up across cpp files, and generated by blender RNA.
See:
https://projects.blender.org/blender/blender/src/branch/main/source/blender/makesrna/intern/rna_ui.cc#L1105-L1399
https://projects.blender.org/blender/blender/src/branch/main/source/blender/makesrna/intern/rna_ui_api.cc#L940-L2057

The properties are in rna_ui.cc, and the python api methods are forwarded to cpp functions in rna_ui_api.cc. As one example,

func = RNA_def_function(srna, "menu_pie", "uiLayoutRadial");
parm = RNA_def_pointer(func, "layout", "UILayout", "", "Sub-layout to put items in");
RNA_def_function_return(func, parm);
RNA_def_function_ui_description(func,
                                  "Sublayout. Items placed in this sublayout are placed "
                                  "in a radial fashion around the menu center)");

we can see that UILayout.menu_pie() is forwarded to free function uiLayoutRadial declared in source/blender/editors/include/UI_interface.h and implemented in source/blender/editors/interface/interface_layout.cc

uiLayout *uiLayoutRadial(uiLayout *layout)
{
  /* radial layouts are only valid for radial menus */
  if (layout->root->type != UI_LAYOUT_PIEMENU) {
    return ui_item_local_sublayout(layout, layout, false);
  }

  /* only one radial wheel per root layout is allowed, so check and return that, if it exists */
  LISTBASE_FOREACH (uiItem *, item, &layout->root->layout->items) {
    uiLayout *litem = (uiLayout *)item;
    if (litem->item.type == ITEM_LAYOUT_RADIAL) {
      UI_block_layout_set_current(layout->root->block, litem);
      return litem;
    }
  }

  uiLayout *litem = MEM_cnew<uiLayout>(__func__);
  ui_litem_init_from_parent(litem, layout, false);

  litem->item.type = ITEM_LAYOUT_RADIAL;

  UI_block_layout_set_current(layout->root->block, litem);

  return litem;
}

The python api UILayout class also corresponds to the cpp api uiLayout struct, declared also in interface_layout.cc:

struct uiLayout {
  uiItem item;

  uiLayoutRoot *root;
  bContextStore *context;
  uiLayout *parent;
  ListBase items;

  char heading[UI_MAX_NAME_STR];

  /** Sub layout to add child items, if not the layout itself. */
  uiLayout *child_items_layout;

  int x, y, w, h;
  float scale[2];
  short space;
  bool align;
  bool active;
  bool active_default;
  bool activate_init;
  bool enabled;
  bool redalert;
  bool keepaspect;
  /** For layouts inside grid-flow, they and their items shall never have a fixed maximal size. */
  bool variable_size;
  char alignment;
  eUIEmbossType emboss;
  /** for fixed width or height to avoid UI size changes */
  float units[2];
};

To Do

The source code can now be inspected to determine where hotkey functionality can be added.

# Followup The implementation for the UILayout class is split up across cpp files, and generated by blender RNA. See: https://projects.blender.org/blender/blender/src/branch/main/source/blender/makesrna/intern/rna_ui.cc#L1105-L1399 https://projects.blender.org/blender/blender/src/branch/main/source/blender/makesrna/intern/rna_ui_api.cc#L940-L2057 The properties are in rna_ui.cc, and the python api methods are forwarded to cpp functions in rna_ui_api.cc. As one [example](https://projects.blender.org/blender/blender/src/branch/main/source/blender/makesrna/intern/rna_ui_api.cc#L1057), ```cpp func = RNA_def_function(srna, "menu_pie", "uiLayoutRadial"); parm = RNA_def_pointer(func, "layout", "UILayout", "", "Sub-layout to put items in"); RNA_def_function_return(func, parm); RNA_def_function_ui_description(func, "Sublayout. Items placed in this sublayout are placed " "in a radial fashion around the menu center)"); ``` we can see that `UILayout.menu_pie()` is forwarded to free function `uiLayoutRadial` declared in [source/blender/editors/include/UI_interface.h](https://projects.blender.org/blender/blender/src/branch/main/source/blender/editors/include/UI_interface.h#L2274) and implemented in [source/blender/editors/interface/interface_layout.cc](https://projects.blender.org/blender/blender/src/branch/main/source/blender/editors/interface/interface_layout.cc#L4953-L4977) ```cpp uiLayout *uiLayoutRadial(uiLayout *layout) { /* radial layouts are only valid for radial menus */ if (layout->root->type != UI_LAYOUT_PIEMENU) { return ui_item_local_sublayout(layout, layout, false); } /* only one radial wheel per root layout is allowed, so check and return that, if it exists */ LISTBASE_FOREACH (uiItem *, item, &layout->root->layout->items) { uiLayout *litem = (uiLayout *)item; if (litem->item.type == ITEM_LAYOUT_RADIAL) { UI_block_layout_set_current(layout->root->block, litem); return litem; } } uiLayout *litem = MEM_cnew<uiLayout>(__func__); ui_litem_init_from_parent(litem, layout, false); litem->item.type = ITEM_LAYOUT_RADIAL; UI_block_layout_set_current(layout->root->block, litem); return litem; } ``` The python api UILayout class also corresponds to the cpp api uiLayout struct, declared also in [interface_layout.cc](https://projects.blender.org/blender/blender/src/branch/main/source/blender/editors/interface/interface_layout.cc#L138-L167): ```cpp struct uiLayout { uiItem item; uiLayoutRoot *root; bContextStore *context; uiLayout *parent; ListBase items; char heading[UI_MAX_NAME_STR]; /** Sub layout to add child items, if not the layout itself. */ uiLayout *child_items_layout; int x, y, w, h; float scale[2]; short space; bool align; bool active; bool active_default; bool activate_init; bool enabled; bool redalert; bool keepaspect; /** For layouts inside grid-flow, they and their items shall never have a fixed maximal size. */ bool variable_size; char alignment; eUIEmbossType emboss; /** for fixed width or height to avoid UI size changes */ float units[2]; }; ``` # To Do The source code can now be inspected to determine where hotkey functionality can be added.

michael campbell commented

2023-07-27 06:05:44 +02:00

just wondering why you'd prefer those keys over the numeric ones? The current numeric shortcuts are laid out on the numpad as they're laid out on screen in the pie menu so that you don't need to look at the keyboard to choose and can do it with one hand.

The ones you're suggesting are all over the place and require two hands even if you're a touch typist.

The aim of the pie menu is to select an option based on it's position on the pie menu, so having their shortcuts be positioned in a similar position under the hand as they are now is better.

If you're going to assign a different shortcut to every pie menu item, then why not just use the shortcut without the pie menu?

Not sure if you realise this by the way, but if you keep the key depressed that opens the pie menu, then move the mouse in the direction of the option you want before letting go, they open without clicking.

just wondering why you'd prefer those keys over the numeric ones? The current numeric shortcuts are laid out on the numpad as they're laid out on screen in the pie menu so that you don't need to look at the keyboard to choose and can do it with one hand. The ones you're suggesting are all over the place and require two hands even if you're a touch typist. The aim of the pie menu is to select an option based on it's position on the pie menu, so having their shortcuts be positioned in a similar position under the hand as they are now is better. If you're going to assign a different shortcut to every pie menu item, then why not just use the shortcut without the pie menu? Not sure if you realise this by the way, but if you keep the key depressed that opens the pie menu, then move the mouse in the direction of the option you want before letting go, they open without clicking.

alegator-rotagela commented

2023-07-27 10:35:34 +02:00

Hi Michael,

It's nice to hear from you!

The ones you're suggesting are all over the place and require two hands even if you're a touch typist.

The ones I suggested are just a random example. The user should be able to configure the hotkeys as they prefer. I prefer my hotkeys to be mostly mnemonic, with some ergonomic concessions. Anyway, you can imagine the first thing someone without a numpad will want is to customize these hotkeys.

Here's a practical example: there are a bunch of selection operators. You can make a modal pie for edit mode on the key 's' so that pressing 'sel' selects edge loops based on the current selection, 'sm' selects more, 'sl' selects less, and so on. The hotkey sequences 'el', 'm', 'l' are only active within the pie bound to 's'. This means that 'e' can be bound to another modal pie for edit mode; pressing 'ee' can extrude edges, 'eb' to bevel edges, 'ebel' to bridge edge loops, and so on. All of these keymaps would be isolated to the pie menu they're defined for.

Let's look at the case 'sel' to see a bit more closely how it should work. The user would prefer to configure this as a key sequence, but the implementation will naturally use nested pies. So pressing 's' in edit mode opens the selection pie, and pressing 'e' in edit mode opens the edge operators pie. But pressing 'e' after 's' opens the select edge pie, which is a nested pie inside the selection pie, and this is a third and distinct pie as far as the implementation and display is concerned.

Blender has modal keymaps like this already implemented. I think the knife tool is a good example. You can read the 2nd link in the Relevant Links section of this post, about hacking modal hotkeys into blender, you can follow the links to a source code excerpt for the knife tool where blender's modal hotkey functionality is used in an operator.

The aim of the pie menu is to select an option based on it's position on the pie menu, so having their shortcuts be positioned in a similar position under the hand as they are now is better.

This is a minor ergonomic concession, for mnemonic and organizational purposes, but users can put the hotkeys next to each other if they prefer. I'll explain a bit why the mnemonic approach is really nice, especially for new users, but also to experienced users. Let's also keep in mind a common pitfall in UI design: they are optimized for beginners at the expense of usability for experts, and note that we can avoid this.

Consider applying this scheme to all menus within modes, and the new user experience. A new user will start by inspecting the mode's dropdown menus, and see that the menus have shortcuts. When they use a menu frequently, they'll remember the shortcut for it, which opens a corresponding pie menu that has all the same functionality as the drop down menu they used before. The user will happily mouse to select inside the pie, but some operators are used so frequently that it would be great to use them even faster. Then the user will start to pay attention to the hotkeys as they mouse through the pies, and over time, they will just begin to press the key sequence. Eventually, experienced users will customize their modal keymaps to be less mnemonic and more streamlined, based on their personalized usage patterns.

So you get a smooth transition from a UI designed for ease of discovery to a UI designed for speed of access, and it's all synchronized, and teaches itself. Blender could even have a tutorial that introduces its features in modular pieces to users, where users would be prompted to make up their own keymap for each module they learn to use as they go.

If you're going to assign a different shortcut to every pie menu item, then why not just use the shortcut without the pie menu?

The shortcuts would only be accessible from within the pie menu. So with the example I gave an image of, if you weren't in the pie menu and you pressed 'r', then you would be pressing the shortcut for object rotation.

concluding remarks

I think the default hotkeys are great for people who have a full keyboard and are already used to them. Likewise, there are blender users working on laptops that are already used to vim (programmers).

It's a lot easier to add modal hotkeys than non-modal hotkeys, because they're isolated and won't interfere with pre-existing hotkeys. This means more functionality can be in the default keymap (preferably all of it).

I'm far from the only user that wants this (see the relevant links), and there are popular plugins that hack their own diy solutions to have modal keymaps.

Hi Michael, It's nice to hear from you! > The ones you're suggesting are all over the place and require two hands even if you're a touch typist. The ones I suggested are just a random example. The user should be able to configure the hotkeys as they prefer. I prefer my hotkeys to be mostly mnemonic, with some ergonomic concessions. Anyway, you can imagine the first thing someone without a numpad will want is to customize these hotkeys. Here's a practical example: there are a bunch of selection operators. You can make a modal pie for edit mode on the key 's' so that pressing 'sel' selects edge loops based on the current selection, 'sm' selects more, 'sl' selects less, and so on. The hotkey sequences 'el', 'm', 'l' are only active within the pie bound to 's'. This means that 'e' can be bound to another modal pie for edit mode; pressing 'ee' can extrude edges, 'eb' to bevel edges, 'ebel' to bridge edge loops, and so on. All of these keymaps would be isolated to the pie menu they're defined for. Let's look at the case 'sel' to see a bit more closely how it should work. The user would prefer to configure this as a key sequence, but the implementation will naturally use nested pies. So pressing 's' in edit mode opens the selection pie, and pressing 'e' in edit mode opens the edge operators pie. But pressing 'e' after 's' opens the select edge pie, which is a nested pie inside the selection pie, and this is a third and distinct pie as far as the implementation and display is concerned. Blender has modal keymaps like this already implemented. I think the knife tool is a good example. You can read the 2nd link in the Relevant Links section of this post, about hacking modal hotkeys into blender, you can follow the links to a source code excerpt for the knife tool where blender's modal hotkey functionality is used in an operator. > The aim of the pie menu is to select an option based on it's position on the pie menu, so having their shortcuts be positioned in a similar position under the hand as they are now is better. This is a minor ergonomic concession, for mnemonic and organizational purposes, but users can put the hotkeys next to each other if they prefer. I'll explain a bit why the mnemonic approach is really nice, especially for new users, but also to experienced users. Let's also keep in mind a common pitfall in UI design: they are optimized for beginners at the expense of usability for experts, and note that we can avoid this. Consider applying this scheme to all menus within modes, and the new user experience. A new user will start by inspecting the mode's dropdown menus, and see that the menus have shortcuts. When they use a menu frequently, they'll remember the shortcut for it, which opens a corresponding pie menu that has all the same functionality as the drop down menu they used before. The user will happily mouse to select inside the pie, but some operators are used so frequently that it would be great to use them even faster. Then the user will start to pay attention to the hotkeys as they mouse through the pies, and over time, they will just begin to press the key sequence. Eventually, experienced users will customize their modal keymaps to be less mnemonic and more streamlined, based on their personalized usage patterns. So you get a smooth transition from a UI designed for ease of discovery to a UI designed for speed of access, and it's all synchronized, and teaches itself. Blender could even have a tutorial that introduces its features in modular pieces to users, where users would be prompted to make up their own keymap for each module they learn to use as they go. > If you're going to assign a different shortcut to every pie menu item, then why not just use the shortcut without the pie menu? The shortcuts would only be accessible from within the pie menu. So with the example I gave an image of, if you weren't in the pie menu and you pressed 'r', then you would be pressing the shortcut for object rotation. ### concluding remarks I think the default hotkeys are great for people who have a full keyboard and are already used to them. Likewise, there are blender users working on laptops that are already used to vim (programmers). It's a lot easier to add modal hotkeys than non-modal hotkeys, because they're isolated and won't interfere with pre-existing hotkeys. This means more functionality can be in the default keymap (preferably all of it). I'm far from the only user that wants this (see the relevant links), and there are popular plugins that hack their own diy solutions to have modal keymaps.

michael campbell commented

2023-07-27 10:58:41 +02:00

Oh OK, I thought you meant you were going to change all the pie menu shortcuts for everyone and that every pie menu would have different keys depending on which operators they were showing.

alegator-rotagela commented

2023-07-27 12:45:38 +02:00

Oh OK, I thought you meant you were going to change all the pie menu shortcuts for everyone

I'm focused on changing my keymaps to what I want, and for other users to be able to do the same. I do not particularly care what the defaults are, but it does make sense to me that Blender ought to have a keymap that can access all of blender's features. It would make the most sense for something like that to be available as a python addon. For that addon to be possible, blender's compiled UI code would have to be extended a bit. Down the line, users would probably like to define modal keymaps in the addon's settings.

If I were to develop that addon, I would name it 'vim-style-keymap-for-laptop-users'

Anyone who doesn't get the addon would have the normal blender hotkeys, but with the changes I'm proposing, the hotkeys for pie menus could be customized by users for each individual pie menu, if the users choose to do that.

and that every pie menu would have different keys depending on which operators they were showing

Yes, that's the idea of the hotkeys being modal, so the user would set the hotkeys to whatever they want and it'll be different in every pie. If the user forgets a shortcut, they can mouse the pie menu.

In the examples I gave, every keypress until the last one is a modal pie. It's like an Ntree. The non-leaf nodes are menu pies, the leaf nodes are operators. The user can move along along the unidirectional nodes of the Ntree by pressing hotkeys, which are displayed next to each option shown in the pie menu.

To constrain the scope of the idea a bit, for now, I would like to focus on just being able to set custom hotkeys for pie menus as they currently function.

Down the line, opening a menu pie from inside a menu pie is a very nice feature; it should be trivial to add because the containing pie can just hide while the nested pie displays at the selection location once the selection is made, either by mouse or hotkey.

Menu pies are also limited to 8 items and this limitation should be removed, in my opinion. This means that for the existing scheme, there would be no shortcuts to assign after the 9th member, and those operators would have to be moused. This would only occur in python addons the user chose to install and enable, so nobody's experience using blender would change

I guess I'll add visualizations later today.

> Oh OK, I thought you meant you were going to change all the pie menu shortcuts for everyone I'm focused on changing *my* keymaps to what I want, and for other users to be able to do the same. I do not particularly care what the defaults are, but it does make sense to me that Blender ought to have a keymap that can access all of blender's features. It would make the most sense for something like that to be available as a python addon. For that addon to be possible, blender's compiled UI code would have to be extended a bit. Down the line, users would probably like to define modal keymaps in the addon's settings. If I were to develop that addon, I would name it 'vim-style-keymap-for-laptop-users' Anyone who doesn't get the addon would have the normal blender hotkeys, but with the changes I'm proposing, the hotkeys for pie menus could be customized by users for each individual pie menu, if the users choose to do that. > and that every pie menu would have different keys depending on which operators they were showing Yes, that's the idea of the hotkeys being modal, so the user would set the hotkeys to whatever they want and it'll be different in every pie. If the user forgets a shortcut, they can mouse the pie menu. In the examples I gave, every keypress until the last one is a modal pie. It's like an Ntree. The non-leaf nodes are menu pies, the leaf nodes are operators. The user can move along along the unidirectional nodes of the Ntree by pressing hotkeys, which are displayed next to each option shown in the pie menu. To constrain the scope of the idea a bit, for now, I would like to focus on just being able to set custom hotkeys for pie menus as they currently function. Down the line, opening a menu pie from inside a menu pie is a very nice feature; it should be trivial to add because the containing pie can just hide while the nested pie displays at the selection location once the selection is made, either by mouse or hotkey. Menu pies are also limited to 8 items and this limitation should be removed, in my opinion. This means that for the existing scheme, there would be no shortcuts to assign after the 9th member, and those operators would have to be moused. This would only occur in python addons the user chose to install and enable, so nobody's experience using blender would change I guess I'll add visualizations later today.

michael campbell commented

2023-07-27 15:36:09 +02:00

I like the idea of multilevel pie menus, but different shortcuts for each of the 8 options for every pie menu, is defeating the idea of a pie menu in my opinion. But if it won't affect how it currently works unless a user wants to change it, then why not.

I think users should be able to limit the number of possible options in the preferences though, so that people don't suddenly have more than 8 options if they want to continue using the same numpad keys for every pie menu variation.

I like the idea of multilevel pie menus, but different shortcuts for each of the 8 options for every pie menu, is defeating the idea of a pie menu in my opinion. But if it won't affect how it currently works unless a user wants to change it, then why not. I think users should be able to limit the number of possible options in the preferences though, so that people don't suddenly have more than 8 options if they want to continue using the same numpad keys for every pie menu variation.

michael campbell commented

2023-07-27 16:17:02 +02:00

Would be nice if your design had an option to mirror global shortcuts, so that people can use it to remind them what the shortcuts are, so next time they don't even need to use the pie menu. Or maybe show the global shortcut and the pie menu shortcut on the key, so they have the option for them to be different....I can't imagine why anyone would want to remember two shortcuts for the same operations though (one for the pie and one for without)

alegator-rotagela commented

2023-07-27 19:46:16 +02:00

I like the idea of multilevel pie menus, but different shortcuts for each of the 8 options for every pie menu, is defeating the idea of a pie menu in my opinion. But if it won't affect how it currently works unless a user wants to change it, then why not.

Yeah I see what you mean, some people might like to interact with all pies the same. I can also imagine someone getting confused when they right click select to change a hotkey in the pie, but they expect it to be that in all pies, and it's only in that one if pies are modal.

To prevent that, perhaps there can be a setting in user preferences to enable modal pies. The users that want this kind of thing will seek it out and enable it no problem.

I think users should be able to limit the number of possible options in the preferences though, so that people don't suddenly have more than 8 options if they want to continue using the same numpad keys for every pie menu variation.

Sure, then any addons the user installs can notify the user to adjust the settings for larger pies if the addon makes use of them.

Would be nice if your design had an option to mirror global shortcuts, so that people can use it to remind them what the shortcuts are, so next time they don't even need to use the pie menu. Or maybe show the global shortcut and the pie menu shortcut on the key, so they have the option for them to be different....

Yeah, the common operations have global shortcuts, and they should be displayed too. You'd use a global hotkey for a frequently used operator.

I can't imagine why anyone would want to remember two shortcuts for the same operations though (one for the pie and one for without)

Modal shortcuts are generally a lot easier to remember because they form acronyms, and are sometimes more comfortable to type because they don't use any modifier keys. Global shortcuts tend to involve holding down several modifiers.

> I like the idea of multilevel pie menus, but different shortcuts for each of the 8 options for every pie menu, is defeating the idea of a pie menu in my opinion. But if it won't affect how it currently works unless a user wants to change it, then why not. Yeah I see what you mean, some people might like to interact with all pies the same. I can also imagine someone getting confused when they right click select to change a hotkey in the pie, but they expect it to be that in all pies, and it's only in that one if pies are modal. To prevent that, perhaps there can be a setting in user preferences to enable modal pies. The users that want this kind of thing will seek it out and enable it no problem. > I think users should be able to limit the number of possible options in the preferences though, so that people don't suddenly have more than 8 options if they want to continue using the same numpad keys for every pie menu variation. Sure, then any addons the user installs can notify the user to adjust the settings for larger pies if the addon makes use of them. > Would be nice if your design had an option to mirror global shortcuts, so that people can use it to remind them what the shortcuts are, so next time they don't even need to use the pie menu. Or maybe show the global shortcut and the pie menu shortcut on the key, so they have the option for them to be different.... Yeah, the common operations have global shortcuts, and they should be displayed too. You'd use a global hotkey for a frequently used operator. > I can't imagine why anyone would want to remember two shortcuts for the same operations though (one for the pie and one for without) Modal shortcuts are generally a lot easier to remember because they form acronyms, and are sometimes more comfortable to type because they don't use any modifier keys. Global shortcuts tend to involve holding down several modifiers.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Pie Menu Hotkey Customization #110496

Summary

Current

Desired

Intro

Motivation

Current State

Desired State

So Far

To Do

Relevant Links

Followup

To Do

concluding remarks