Keymap system refactor #68884

New Issue

Dalai Felinto · 2019-08-20T19:35:49+02:00

Dalai Felinto commented

2019-08-20 19:35:49 +02:00

Listing issues with the current key-map system.

Key-Map System

Timers should be removed from the key-map, since they are for internal operations.
Action-zones should be removed from key-maps.

User Interface

The ability to re-order key-map items.

This is important as key-map items are handled in the order listed, with some items passing on to key-map items defined afterwards.

Ability to select from existing operators list instead of typing in a string (similar to selecting ID's bones... etc).
Other features:
- Remove duplicate key-map items.
- Show invalid key-map items (missing operators, reference to invalid menu items... etc).
- Disallow assigning invalid/duplicate key-map items when using "Assign Shortcut".

Open Topics

These are larger issues which need design work, which this proposal doesn't (yet) handle, and it's not clear exactly how these would be handled.

Exporting key-maps looses the ability to access key-map preferences.
Mapping keys from keyboards which have keys not found on a US/English keyboard.
Workflow for editing and maintaining custom key-maps could be looked into & improved.

Listing issues with the current key-map system. Key-Map System -------------- - Timers should be removed from the key-map, since they are for internal operations. - Action-zones should be removed from key-maps. User Interface -------------- - The ability to re-order key-map items. ``` This is important as key-map items are handled in the order listed, with some items passing on to key-map items defined afterwards. ``` - Ability to select from existing operators list instead of typing in a string (similar to selecting ID's bones... etc). - Other features: - Remove duplicate key-map items. - Show invalid key-map items (missing operators, reference to invalid menu items... etc). - Disallow assigning invalid/duplicate key-map items when using "Assign Shortcut". Open Topics ----------- These are larger issues which need design work, which this proposal doesn't (yet) handle, and it's not clear exactly how these would be handled. - Exporting key-maps looses the ability to access key-map preferences. - Mapping keys from keyboards which have keys not found on a US/English keyboard. - Workflow for editing and maintaining custom key-maps could be looked into & improved.

Dalai Felinto commented

2019-08-20 19:35:49 +02:00

Added subscriber: @dfelinto

blender-admin commented

2019-08-20 19:35:49 +02:00

#84079 was marked as duplicate of this issue

Asher commented

2019-08-20 21:44:26 +02:00

Added subscriber: @ThatAsherGuy

Duarte Farrajota Ramos commented

2019-08-20 22:13:48 +02:00

Added subscriber: @DuarteRamos

Demeter Dzadik commented

2019-08-27 23:20:45 +02:00

Added subscriber: @Mets

Alberto Velázquez commented

2019-10-04 23:32:31 +02:00

Added subscriber: @AlbertoVelazquez

Campbell Barton commented

2020-01-20 08:46:55 +01:00

Changed status from 'Confirmed' to: 'Needs User Info'

Campbell Barton commented

2020-01-20 08:49:42 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2020-01-20 08:49:42 +01:00

Could basic details be added to this task, even if the design isn't yet done.

From the title, it's not obvious what this task refers to, it could mean anything from changes to GHOST's handling of non US keyboards to updates to the UI.

Could basic details be added to this task, even if the design isn't yet done. From the title, it's not obvious what this task refers to, it could mean anything from changes to GHOST's handling of non US keyboards to updates to the UI.

Chris Kohl commented

2020-02-24 09:09:23 +01:00

Added subscriber: @ckohl_art

Demeter Dzadik commented

2020-03-05 12:07:57 +01:00

Will the hotkey system be merely getting a refactor/code cleanup? Or more like, an overhaul, including functionality? :)

It could really use the latter, imo, but I won't tire anyone with a long rant if the former is what this thread is for.

Will the hotkey system be merely getting a refactor/code cleanup? Or more like, an overhaul, including functionality? :) It could really use the latter, imo, but I won't tire anyone with a long rant if the former is what this thread is for.

Campbell Barton commented

2020-03-16 01:06:22 +01:00

@Mets while I'm didn't create this task, I listed known issues with the keymap system (things that as far as I know - maintainers of these areas would agree on).

If you have further suggestions, could you write them up?

Note that I'm not sure if there is time for larger refactor at the moment, it would just be interesting to know what issues you propose to solve with larger changes.

@Mets while I'm didn't create this task, I listed known issues with the keymap system *(things that as far as I know - maintainers of these areas would agree on).* If you have further suggestions, could you write them up? Note that I'm not sure if there is time for larger refactor at the moment, it would just be interesting to know what issues you propose to solve with larger changes.

Duarte Farrajota Ramos commented

2020-03-16 01:20:39 +01:00

I do like to spend some considerable time tweaking keymaps.
The ability to reorder items will be a very welcome addition indeed and was high on my list. Picking from a list of available operators will also help.

UI wise, related to reordering one thing like to see the ability to add a new entries at any random point in the list, rather than just have am Add New button at the end. (Maybe through a button visible only on mouse hover?)

Ability to add new keys while in filtered view (by entering a search term at the top search box) is also very useful.
Given the complexity and extensive nature of the theymap one often has to do a search to find the correct context to enter a new keymap by checking where similar ones are placed.
Being able to enter one directly from search view will avoid a lot of blind searching and pinning down existing maps. Maybe the ability to duplicate an existing entry would also help.

The holy grail of keymap editing would be marking existing conflicts, but I suspect this is not trivial to do except for the most obvious of cases, given the complexity of possible combinations.

"Sticky headers" with always visible search box and import export buttons are probably a more generic improvement to the preferences window that would benefit other panes like addons, rather that a specific keymap improvement, and likely out of scope here. Sticky categories for the keymap tree would also help a user know where they currently are.

I do like to spend some considerable time tweaking keymaps. The ability to reorder items will be a very welcome addition indeed and was high on my list. Picking from a list of available operators will also help. UI wise, related to reordering one thing like to see the ability to add a new entries at any random point in the list, rather than just have am *Add New* button at the end. (Maybe through a button visible only on mouse hover?) Ability to add new keys while in filtered view (by entering a search term at the top search box) is also very useful. Given the complexity and extensive nature of the theymap one often has to do a search to find the correct context to enter a new keymap by checking where similar ones are placed. Being able to enter one directly from search view will avoid a lot of blind searching and pinning down existing maps. Maybe the ability to duplicate an existing entry would also help. The holy grail of keymap editing would be marking existing conflicts, but I suspect this is not trivial to do except for the most obvious of cases, given the complexity of possible combinations. "Sticky headers" with always visible search box and import export buttons are probably a more generic improvement to the preferences window that would benefit other panes like addons, rather that a specific keymap improvement, and likely out of scope here. Sticky categories for the keymap tree would also help a user know where they currently are.

Demeter Dzadik commented

2020-03-16 16:16:26 +01:00

My dream shortcut editor would look something like this:

Avoiding duplicate shortcuts
Let shortcuts be assigned to multiple contexts. For example right now, the "Scale B-Bone" shortcut is duplicated in the "Pose" and "Armature" contexts. Instead, shortcuts would be able to have any number of contexts in which they are available, so we can have a single "Scale B-Bone" shortcut, and assign it to those two contexts.

Shortcut categories
I've been referring to these as contexts, I hope that's correct. I'm hoping it would be possible to organize the current contexts in blender into a sort of hierarchy - similar to how it is already done, just with a few changes. The goal would be that a single context has all of its potentially shortcut-conflicting contexts as a parent. For example:

Window
- 3D View
  - Pose
    - Weight Paint
      This hierarchy implies that any shortcut that has Weight Paint as one of its contexts should be checked for conflicts against the Pose, 3D View and Window contexts. I don't know if there are any corner cases where this wouldn't work, but I can't think of any right now.

Shortcut Editor UI
The Shortcut Editor is a separate editor from the User Preferences. It can be opened from Edit->Shortcuts(or so)
It is split into three main columns:
On the left is a nested list of contexts, similar to what we have now, except they are selectable. By default, the root of this hierarchy is selected, which is the "Window" context. (Since I believe these shortcuts are available from anywhere in Blender)
In the center of the shortcut editor UI is a graphic of a keyboard layout. Perhaps there is a drop-down to choose other supported input devices, and perhaps the keyboard layout adjusts to non-english or non-standard layouts.
To the right of the input device graphic, is a list of shortcuts available in the selected context. This is where shortcuts can be filtered, modified, added and removed, ie. all the things we can do in today's Blender.

UX
Scenario: We want to add a new shortcut in Weight Paint and Mesh Edit modes to the Smooth Vertex Weight operator. "Smooth" starts with S, so that would be easy to remember, but we want to avoid conflicts of course.
We start by finding and selecting the Weight Paint context in the left side menu. We find it under Window->3D View->Pose->Weight Paint, and we select it. (Only one context can be selected at once.)
We notice that on the keyboard in the center, keys which have a shortcut assigned to them in this context(or any parent context) become highlighted in some color, and the shortcut list on the right side is updated with more shortcuts. Because of the color coding, it's immediately clear if there are any keys that are completely free. (But for this example, we already set our mind on the S key.)

Hovering over a key shows a list of shortcuts in a floater next to our mouse cursor that use that key, eg if you hover over the S key, you see:

Ctrl: Save File (Window)
Ctrl Shift: Save As (Window)
S: Resize (3D View)
Alt: Clear Pose Scale (Pose)
Ctrl Alt: Scale B-Bone (Pose)

Clicking on the key will highlight it and filter the shortcut list on the right side, to show only shortcuts with this key in them, ie. the 5 shortcuts we saw while hovering over it. You can click it again to deselect that key and remove the filtering. Any number of keys can be selected at once.

So now your selected context is Weight Paint, your selected key is S, and you press "Add Shortcut". A new shortcut is created with just the S key, and the Weight Paint context added.

If user wants to change the shortcut key from S to A, we want to make sure the shortcut being edited doesn't disappear because of the filtering, so in this case we would automatically select the A key, or deselect the S key.

Similar handling if the user wants to change the shortcut's context from Weight Paint to something else - We would also change the selected context in the left-side context list, to keep the edited shortcut on the screen.
In the shortcut's UI, there is an "Add Context" button, which lets you select Window->3D View->Mesh as the second context for this shortcut.
You can also remove contexts. To delete the shortcut entirely, you would simply remove the final context.

Conflict detection and handling
We check all parent contexts recursively for identical key combinations. This relies on my earlier assumption, about being able to organize contexts into a hierarchy.
A warning appears on the newly added S shortcut: Conflict with "Resize" shortcut from "3D View" context.
There is also now a warning icon in the contex list: Weight Paint (!)
When you mouse-over the S key in the keyboard graphics, there is now a new line:

S: (Weight Paint) **(!)**You enable all of the Ctrl Alt Shift modifier keys to resolve the conflict and make all the warnings disappear.Operator Search
You already touched on this in the post - There should be a search instead of having to type in the operator's idname. In a perfect world, this would only show operators which are available in all the contexts that this shortcut is assigned to, but I'm not sure if that's possible, since poll() functions can be more complex than just checking the current editor type and object mode.

One way or another, it would probably still be possible for the user to make a non-sensical shortcut+context combinations. For example, if they want to have their shortcut for the Smooth Vertex Weights operator available in the Armature Edit Mode context, and they tried to use that shortcut, it would fail with a poll() error. And I guess that's okay. Powerful tools are never foolproof. Although more useful error messages are always welcome.

Right Click->Assign/Change Shortcut
Currently a tiny input bar pops up and immediately disappears as soon as a non-modifier key is pressed, and it creates the new shortcut. This is fast and can be convenient, but it's not very powerful. I would say in 95% of cases when I used this, I then had to find the new shortcut in the shortcut editor, and customize it to be the way I wanted. So I wish that that popover would be more akin to the new Add/Edit driver popovers. So it wouldn't quite open a fully fledged Shortcut Editor window that then has to be closed, but just a small popover showing everything to do with the shortcut that's about to be created. One difference I would have between this and Add/Edit driver, is to have to confirm the creation of the shortcut by pressing an "OK" button.

Well, that was a giant wall of text, and I'm sure this is 900% out of scope, but you asked for it! :)

Here's a visual example although the software(Wonder Unit Storyboarder) is very different and much simpler than Blender, just to help get the idea across:

My dream shortcut editor would look something like this: **Avoiding duplicate shortcuts** Let shortcuts be assigned to multiple contexts. For example right now, the "Scale B-Bone" shortcut is duplicated in the "Pose" and "Armature" contexts. Instead, shortcuts would be able to have any number of contexts in which they are available, so we can have a single "Scale B-Bone" shortcut, and assign it to those two contexts. **Shortcut categories** I've been referring to these as contexts, I hope that's correct. I'm hoping it would be possible to organize the current contexts in blender into a sort of hierarchy - similar to how it is already done, just with a few changes. The goal would be that a single context has all of its potentially shortcut-conflicting contexts as a parent. For example: - Window - 3D View - Pose - Weight Paint This hierarchy implies that any shortcut that has Weight Paint as one of its contexts should be checked for conflicts against the Pose, 3D View and Window contexts. I don't know if there are any corner cases where this wouldn't work, but I can't think of any right now. **Shortcut Editor UI** The Shortcut Editor is a separate editor from the User Preferences. It can be opened from Edit->Shortcuts(or so) It is split into three main columns: On the left is a nested list of contexts, similar to what we have now, except they are selectable. By default, the root of this hierarchy is selected, which is the "Window" context. (Since I believe these shortcuts are available from anywhere in Blender) In the center of the shortcut editor UI is a graphic of a keyboard layout. Perhaps there is a drop-down to choose other supported input devices, and perhaps the keyboard layout adjusts to non-english or non-standard layouts. To the right of the input device graphic, is a list of shortcuts available in the selected context. This is where shortcuts can be filtered, modified, added and removed, ie. all the things we can do in today's Blender. **UX** Scenario: We want to add a new shortcut in Weight Paint and Mesh Edit modes to the Smooth Vertex Weight operator. "Smooth" starts with S, so that would be easy to remember, but we want to avoid conflicts of course. We start by finding and selecting the Weight Paint context in the left side menu. We find it under Window->3D View->Pose->Weight Paint, and we select it. (Only one context can be selected at once.) We notice that on the keyboard in the center, keys which have a shortcut assigned to them in this context(or any parent context) become highlighted in some color, and the shortcut list on the right side is updated with more shortcuts. Because of the color coding, it's immediately clear if there are any keys that are completely free. (But for this example, we already set our mind on the `S` key.) Hovering over a key shows a list of shortcuts in a floater next to our mouse cursor that use that key, eg if you hover over the `S` key, you see: - Ctrl: Save File *(Window)* - Ctrl Shift: Save As *(Window)* - S: Resize *(3D View)* - Alt: Clear Pose Scale *(Pose)* - Ctrl Alt: Scale B-Bone *(Pose)* Clicking on the key will highlight it and filter the shortcut list on the right side, to show only shortcuts with this key in them, ie. the 5 shortcuts we saw while hovering over it. You can click it again to deselect that key and remove the filtering. Any number of keys can be selected at once. So now your selected context is Weight Paint, your selected key is S, and you press "Add Shortcut". A new shortcut is created with just the `S` key, and the Weight Paint context added. If user wants to change the shortcut key from `S` to `A`, we want to make sure the shortcut being edited doesn't disappear because of the filtering, so in this case we would automatically select the `A` key, or deselect the `S` key. Similar handling if the user wants to change the shortcut's context from Weight Paint to something else - We would also change the selected context in the left-side context list, to keep the edited shortcut on the screen. In the shortcut's UI, there is an "Add Context" button, which lets you select Window->3D View->Mesh as the second context for this shortcut. You can also remove contexts. To delete the shortcut entirely, you would simply remove the final context. **Conflict detection and handling** We check all parent contexts recursively for identical key combinations. This relies on my earlier assumption, about being able to organize contexts into a hierarchy. A warning appears on the newly added `S` shortcut: `Conflict with "Resize" shortcut from "3D View" context.` There is also now a warning icon in the contex list: `Weight Paint (!)` When you mouse-over the S key in the keyboard graphics, there is now a new line: - S: <none> *(Weight Paint)* **(!)**You enable all of the Ctrl Alt Shift modifier keys to resolve the conflict and make all the warnings disappear.**Operator Search** You already touched on this in the post - There should be a search instead of having to type in the operator's idname. In a perfect world, this would only show operators which are available in all the contexts that this shortcut is assigned to, but I'm not sure if that's possible, since poll() functions can be more complex than just checking the current editor type and object mode. One way or another, it would probably still be possible for the user to make a non-sensical shortcut+context combinations. For example, if they want to have their shortcut for the Smooth Vertex Weights operator available in the Armature Edit Mode context, and they tried to use that shortcut, it would fail with a poll() error. And I guess that's okay. Powerful tools are never foolproof. Although more useful error messages are always welcome. **Right Click->Assign/Change Shortcut** Currently a tiny input bar pops up and immediately disappears as soon as a non-modifier key is pressed, and it creates the new shortcut. This is fast and can be convenient, but it's not very powerful. I would say in 95% of cases when I used this, I then had to find the new shortcut in the shortcut editor, and customize it to be the way I wanted. So I wish that that popover would be more akin to the new Add/Edit driver popovers. So it wouldn't quite open a fully fledged Shortcut Editor window that then has to be closed, but just a small popover showing everything to do with the shortcut that's about to be created. One difference I would have between this and Add/Edit driver, is to have to confirm the creation of the shortcut by pressing an "OK" button. Well, that was a giant wall of text, and I'm sure this is 900% out of scope, but you asked for it! :) Here's a visual example although the software(Wonder Unit Storyboarder) is very different and much simpler than Blender, just to help get the idea across: ![keyboard2.gif](https://archive.blender.org/developer/F8454375/keyboard2.gif)

Roman Kornev commented

2020-04-05 13:04:35 +02:00

Added subscriber: @RomanKornev

Petter Lundh commented

2020-04-24 10:56:23 +02:00

Added subscriber: @PetterLundh

xan2622 commented

2020-05-08 20:09:48 +02:00

Added subscriber: @xan2622

Gilberto Rodrigues commented

2020-05-15 07:47:08 +02:00

Added subscriber: @Gilberto.R

Gilberto Rodrigues commented

2020-05-15 07:47:08 +02:00

This comment was removed by @Gilberto.R

*This comment was removed by @Gilberto.R*

David Friedli commented

2020-05-15 12:00:43 +02:00

Added subscriber: @hlorus

David Friedli commented

2020-05-15 12:00:43 +02:00

This comment was removed by @hlorus

*This comment was removed by @hlorus*

Campbell Barton commented

2020-05-29 09:00:32 +02:00

This task is not for general help on making keymaps, for this use sites like blenderartist or blender.stackexchange.

Paul Kotelevets commented

2020-06-13 09:28:18 +02:00

Added subscriber: @1D_Inc

Paul Kotelevets commented

2020-06-13 09:28:18 +02:00

In #68884#892054, @Mets wrote:

Here's a visual example although the software(Wonder Unit Storyboarder) is very different and much simpler than Blender, just to help get the idea across:

Storyboarder have simple keys layout that allow to display and control them in key-oriented way.
Blender is a wide scope application with complex keys layout, including modals, that's why it have operator-oriented keys editing preferences.

> In #68884#892054, @Mets wrote: > Here's a visual example although the software(Wonder Unit Storyboarder) is very different and much simpler than Blender, just to help get the idea across: > ![keyboard2.gif](https://archive.blender.org/developer/F8454375/keyboard2.gif) Storyboarder have simple keys layout that allow to display and control them in key-oriented way. Blender is a wide scope application with complex keys layout, including modals, that's why it have operator-oriented keys editing preferences.

Philipp Oeser commented

2020-06-23 10:23:36 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-06-23 10:23:36 +02:00

@dfelinto , @ideasman42 , others: not sure how we can get this task out of the Needs Information From User limbo?

@dfelinto , @ideasman42 , others: not sure how we can get this task out of the `Needs Information From User` limbo?

Demeter Dzadik commented

2020-06-23 11:34:47 +02:00

@1D_Inc

The context hierarchy system accounts for modal operators, just like in the current system. A more complex piece of software that has a similar editor is apparently Maya

(Image removed - See CopyrightRules)

I'm against 95% of UI decisions made in Maya, but I did actually use this hotkey editor years ago to make Maya behave more like Blender - and it was very easy to customize the hotkeys. Complexity can be broken down, and hopefully that's exactly what the context hierarchy does (already). The ideas I described I think change the actual system very little - it mostly just changes how things are displayed.

@1D_Inc The context hierarchy system accounts for modal operators, just like in the current system. A more complex piece of software that has a similar editor is apparently Maya (**Image removed** - See [CopyrightRules](https://wiki.blender.org/wiki/Communication/CopyrightRules)) I'm against 95% of UI decisions made in Maya, but I did actually use this hotkey editor years ago to make Maya behave more like Blender - and it was very easy to customize the hotkeys. Complexity can be broken down, and hopefully that's exactly what the context hierarchy does (already). The ideas I described I think change the actual system very little - it mostly just changes how things are displayed.

Paul Kotelevets commented

2020-06-23 12:12:27 +02:00

In #68884#962993, @Mets wrote:
A more complex piece of software that has a similar editor is apparently Maya
(Image removed - See CopyrightRules)

Yes, it is used there as a viewer with the ability to edit layout (not as main editor), and using this approach as a viewer cause no problems, because viewers just represents data in some readable way.
Developers proposed using such a layout as the main editor, which does not correspond to the complexity of the software.

> In #68884#962993, @Mets wrote: > A more complex piece of software that has a similar editor is apparently Maya > (**Image removed** - See [CopyrightRules](https://wiki.blender.org/wiki/Communication/CopyrightRules)) Yes, it is used there as a viewer with the ability to edit layout (not as main editor), and using this approach as a viewer cause no problems, because viewers just represents data in some readable way. Developers [proposed ](https://developer.blender.org/T76678) using such a layout as the main editor, which does not correspond to the complexity of the software.

Demeter Dzadik commented

2020-06-23 23:36:00 +02:00

I haven't done a perfect perfect job of getting my idea across in a more visual sense, but I think this part is relevant to your point, and tackles the issue:

To the right of the input device graphic, is a list of shortcuts available in the selected context. This is where shortcuts can be filtered, modified, added and removed, ie. all the things we can do in today's Blender.

This is effectively the exact same menu that currently exists in Blender, and it would continue to function 95% the same way. So I don't think you'd be losing anything. Certainly not the ability to have an overview of assigned operators in a context. That would totally still be there, and it would be one of the three top-level UI elements.

I haven't done a perfect perfect job of getting my idea across in a more visual sense, but I think this part is relevant to your point, and tackles the issue: > To the right of the input device graphic, is a list of shortcuts available in the selected context. This is where shortcuts can be filtered, modified, added and removed, ie. all the things we can do in today's Blender. This is effectively the exact same menu that currently exists in Blender, and it would continue to function 95% the same way. So I don't think you'd be losing anything. Certainly not the ability to have an overview of assigned operators in a context. That would totally still be there, and it would be one of the three top-level UI elements.

Paul Kotelevets commented

2020-06-24 11:06:58 +02:00

In #68884#963599, @Mets wrote:
To the right of the input device graphic, is a list of shortcuts available in the selected context.
This is effectively the exact same...

Yes, I know that.
But the problem is that the proposal made by the developers does not include such a list of shortcuts available in the selected context. They want to make it even more primitive than in Wonder Unit Storyboarder style, with only graphic and no list.
So we both have to explain this issue to devs, not to me, right?

> In #68884#963599, @Mets wrote: > To the right of the input device graphic, is a list of shortcuts available in the selected context. > This is effectively the exact same... Yes, I know that. [But the problem is that the proposal made by the developers does not include such a list of shortcuts available in the selected context. They want to make it even more primitive than in Wonder Unit Storyboarder style, with only graphic and no list.](https://developer.blender.org/T76678) So we both have to explain this issue to devs, not to me, right?

Demeter Dzadik commented

2020-06-24 11:23:56 +02:00

Ah, for sure, I'm all for that :) But looking at the roadmap and weekly reports, the devs are understandably busy with more important projects, so I think this area is fairly low priority atm. Which is fair, the current system is completely functional, it's just hard for new users is all.

I wonder if I could at least partially implement a prototype of my idea in python, as a proof of concept if nothing else... I'll keep that on my mind, but no idea when I might find the time.

Ah, for sure, I'm all for that :) But looking at the roadmap and weekly reports, the devs are understandably busy with more important projects, so I think this area is fairly low priority atm. Which is fair, the current system is completely functional, it's just hard for new users is all. I wonder if I could at least partially implement a prototype of my idea in python, as a proof of concept if nothing else... I'll keep that on my mind, but no idea when I might find the time.

Julian Eisel commented

2020-06-24 11:44:21 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2020-06-24 11:44:21 +02:00

@ideasman42 do you plan to work on this short-term-ish?

While I think we all agree that the keymap editor/system needs work, I'm not sure if we should make this a goal for the 2.9x series.
The current UI team plan is to focus on wrapping up the 2.8 project for that series and avoid adding new projects. The keymap editor changes will take a while to complete and take attention from other tasks. Especially if we want to do it properly.

(I'm not at all discouraging design work and feedback though, just questioning if the UI team should prioritize this right now.)

@ideasman42 do you plan to work on this short-term-ish? While I think we all agree that the keymap editor/system needs work, I'm not sure if we should make this a goal for the 2.9x series. The current UI team plan is to focus on wrapping up the 2.8 project for that series and avoid adding new projects. The keymap editor changes will take a while to complete and take attention from other tasks. Especially if we want to do it properly. (I'm not at all discouraging design work and feedback though, just questioning if the UI team should prioritize this right now.)

Cy commented

2020-07-10 19:02:05 +02:00

Added subscriber: @TheCGCy

Cy commented

2020-07-10 19:02:05 +02:00

Hi, I have question regarding to this report I created https://developer.blender.org/T78628 . Does this also falls into keymap System refactor? It's sounds like one of the issue of looses the ability to access key-map preferences, but the one I mentioned is it replacing other keys while creating new set.