Visual Keymap Editor #76678

Open
opened 2020-05-12 13:40:49 +02:00 by William Reynish · 52 comments

While Blender's keymap editor is very flexible, it isn't very easy to get a clear overview, to spot conflicts, or to edit in general.

Issues with the current keymap editor:

  • It's hard to get an overview of the keyboard
  • You cannot easily see how a given keymap works
  • It's very hard or impossible to tell which keys are free vs used
  • No way to print out to get an overview
  • It's not possible to tell if there's a conflict
  • It's not easy to see which entries are custom vs 'original'

We can solve these issues with a new approach for how the keymap editor should work:

Screenshot 2020-05-12 at 13.31.32.png

Rather than just listing entries in a long nested list, we can do something more visual that shows the layout of the keyboard.

Above the keyboard, users can choose which editor and which mode to see. You can also pick if you want to edit the main keyboard, the keypad, or the mouse buttons:
Screenshot 2020-05-12 at 13.32.52.png

An example of how the Mouse section could work:
Screenshot 2020-05-12 at 14.43.22.png

In the top right you can choose which modifiers to take into account for the keyboard below. In this case Shift is enabled, so we only show items that are activated while holding Shift.
Screenshot 2020-05-12 at 13.33.41.png

The keys themselves highlight if there is a shortcut added. The blue key here is the one that is selected. The dot means that it was customized. The warning symbol means there is a conflict on this key.
Screenshot 2020-05-12 at 13.35.57.png

When a key is selected, you can see the operator assigned to it below. This is similar to the current keymap editor:
Screenshot 2020-05-12 at 13.37.49.png

On the left we have a way to search for all operators, filtered by the current context, which you can apply to the current key in one of two ways:

  • Either by first selecting the key, then searching for an operator and clicking Apply.
  • Or, you could simply search for an operator and drag it directly onto a key

Normally you see a list of all operators which apply in the current context:
Screenshot 2020-05-12 at 13.55.51.png

You can search this list to narrow the results down:
Screenshot 2020-05-12 at 13.38.37.png

While Blender's keymap editor is very flexible, it isn't very easy to get a clear overview, to spot conflicts, or to edit in general. Issues with the current keymap editor: - It's hard to get an overview of the keyboard - You cannot easily see how a given keymap works - It's very hard or impossible to tell which keys are free vs used - No way to print out to get an overview - It's not possible to tell if there's a conflict - It's not easy to see which entries are custom vs 'original' We can solve these issues with a new approach for how the keymap editor should work: ![Screenshot 2020-05-12 at 13.31.32.png](https://archive.blender.org/developer/F8530506/Screenshot_2020-05-12_at_13.31.32.png) Rather than just listing entries in a long nested list, we can do something more visual that shows the layout of the keyboard. Above the keyboard, users can choose which editor and which mode to see. You can also pick if you want to edit the main keyboard, the keypad, or the mouse buttons: ![Screenshot 2020-05-12 at 13.32.52.png](https://archive.blender.org/developer/F8530511/Screenshot_2020-05-12_at_13.32.52.png) An example of how the Mouse section could work: ![Screenshot 2020-05-12 at 14.43.22.png](https://archive.blender.org/developer/F8530643/Screenshot_2020-05-12_at_14.43.22.png) In the top right you can choose which modifiers to take into account for the keyboard below. In this case Shift is enabled, so we only show items that are activated while holding Shift. ![Screenshot 2020-05-12 at 13.33.41.png](https://archive.blender.org/developer/F8530517/Screenshot_2020-05-12_at_13.33.41.png) The keys themselves highlight if there is a shortcut added. The blue key here is the one that is selected. The dot means that it was customized. The warning symbol means there is a conflict on this key. ![Screenshot 2020-05-12 at 13.35.57.png](https://archive.blender.org/developer/F8530521/Screenshot_2020-05-12_at_13.35.57.png) When a key is selected, you can see the operator assigned to it below. This is similar to the current keymap editor: ![Screenshot 2020-05-12 at 13.37.49.png](https://archive.blender.org/developer/F8530526/Screenshot_2020-05-12_at_13.37.49.png) On the left we have a way to search for all operators, filtered by the current context, which you can apply to the current key in one of two ways: - Either by first selecting the key, then searching for an operator and clicking Apply. - Or, you could simply search for an operator and drag it directly onto a key Normally you see a list of all operators which apply in the current context: ![Screenshot 2020-05-12 at 13.55.51.png](https://archive.blender.org/developer/F8530555/Screenshot_2020-05-12_at_13.55.51.png) You can search this list to narrow the results down: ![Screenshot 2020-05-12 at 13.38.37.png](https://archive.blender.org/developer/F8530528/Screenshot_2020-05-12_at_13.38.37.png)
William Reynish self-assigned this 2020-05-12 13:40:49 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscriber: @WilliamReynish

Added subscriber: @WilliamReynish

Added subscribers: @pablovazquez, @ideasman42

Added subscribers: @pablovazquez, @ideasman42
Member

Added subscriber: @JacquesLucke

Added subscriber: @JacquesLucke
Member

Is the keyboard layout supposed to look different depending on the keyboard the user uses?

Is the keyboard layout supposed to look different depending on the keyboard the user uses?

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos

@JacquesLucke Ideally it would take the current input language into account, but not sure how feasible it is to add support for all regions. But, some select ones would probably need to be added, like an AZERTY layout. Ideally it would simply auto-detect the input language so that it 'just works'.

@JacquesLucke Ideally it would take the current input language into account, but not sure how feasible it is to add support for all regions. But, some select ones would probably need to be added, like an AZERTY layout. Ideally it would simply auto-detect the input language so that it 'just works'.

Added subscriber: @AnadinX

Added subscriber: @AnadinX

This looks great I do have a use-case where its slightly less useful..

I like the built in keymap but change my navigation controls to be the usual ATL+LMB/MMB/RMB. I do this across all editors/contexts. its currently quite easy to modify all editor versions of similar keymaps by using the search.

image.png

This may be something that's less important but thought it was worth mentioning as there are a number of things that are shared (circle/box selected for instance)

With this proposal we'd have to switch editor manually again to see if that editor even had the mapping.

This looks great I do have a use-case where its slightly less useful.. I like the built in keymap but change my navigation controls to be the usual ATL+LMB/MMB/RMB. I do this across all editors/contexts. its currently quite easy to modify all editor versions of similar keymaps by using the search. ![image.png](https://archive.blender.org/developer/F8531501/image.png) This may be something that's less important but thought it was worth mentioning as there are a number of things that are shared (circle/box selected for instance) With this proposal we'd have to switch editor manually again to see if that editor even had the mapping.
Member

Added subscriber: @Imaginer

Added subscriber: @Imaginer
Member

I like this in general, but I'd also like to request that an "Advanced Mode" be retained which would show the version we have now, because of things like what @AnadinX said about having a list that spans multiple contexts, and for the ability to have multiple keymaps open at the same time which it looks like the new design wouldn't allow. But for general use and conflict detection this looks like a great improvement!

I like this in general, but I'd also like to request that an "Advanced Mode" be retained which would show the version we have now, because of things like what @AnadinX said about having a list that spans multiple contexts, and for the ability to have multiple keymaps open at the same time which it looks like the new design wouldn't allow. But for general use and conflict detection this looks like a great improvement!

Added subscriber: @AlexeyPerminov

Added subscriber: @AlexeyPerminov

Added subscriber: @ckohl_art

Added subscriber: @ckohl_art

Added subscriber: @CobraA

Added subscriber: @CobraA

I too agree, this one seems you can navigate & change one thing at time which would be slow to customize an entire keymap while the current one allows for much more flexibilty it's just a long list of scrolling when it should have been a multi-column layout

I too agree, this one seems you can navigate & change one thing at time which would be slow to customize an entire keymap while the current one allows for much more flexibilty it's just a long list of scrolling when it should have been a multi-column layout

Added subscriber: @deadpin

Added subscriber: @deadpin

I think the primary reason why folks would want to retain an "advanced" list of entries that span multiple contexts at once is because there's no hierarchy to the keymap. In many instances I want to add/change a keymap entry at a "top level" and have it apply to everything below that unless overridden later.

Why do I have to add/change the same keymap entry (key and action) for both "Object Mode" and "Mesh" today? What I really want is to add/change that entry for "Viewport" and have it apply to object mode and mesh accordingly.

Why do I have to add/change the same keymap entry (key and action) 3 times for "Object Mode", "Mesh", and "Curve" modes when they will all call the same pie menu using the same key? What I really want to say is just add this pie menu entry to the "Viewport" and have it apply in all the lower modes.

You could still override entries for things like "Mesh" mode individually but for the most part I want a top level hierarchy so I can set most things once.

Beyond that, being able to draw the various keyboard and mouse layouts will probably be very difficult although I really do like it :)

If a hierarchy won't be added, consider allowing multiple "contexts" to be selected at once in your selector maybe? Then display all the actions somehow on the same keyboard layout. It would allow folks to modify all the contexts they have selected at once. Would get messy real quick. At least consider it and mention it in the design even if you chose to not do it.

I think the primary reason why folks would want to retain an "advanced" list of entries that span multiple contexts at once is because there's no hierarchy to the keymap. In many instances I want to add/change a keymap entry at a "top level" and have it apply to everything below that unless overridden later. Why do I have to add/change the same keymap entry (key and action) for both "Object Mode" and "Mesh" today? What I really want is to add/change that entry for "Viewport" and have it apply to object mode and mesh accordingly. Why do I have to add/change the same keymap entry (key and action) 3 times for "Object Mode", "Mesh", and "Curve" modes when they will all call the same pie menu using the same key? What I really want to say is just add this pie menu entry to the "Viewport" and have it apply in all the lower modes. You could still override entries for things like "Mesh" mode individually but for the most part I want a top level hierarchy so I can set most things once. Beyond that, being able to draw the various keyboard and mouse layouts will probably be very difficult although I really do like it :) If a hierarchy won't be added, consider allowing multiple "contexts" to be selected at once in your selector maybe? Then display all the actions somehow on the same keyboard layout. It would allow folks to modify all the contexts they have selected at once. Would get messy real quick. At least consider it and mention it in the design even if you chose to not do it.
Member

@deadpin
You can already do that. Just add a keymap entry to the 3D View (Global) section (or the Window section which is truly global). This will make it work in any mode, so long as a keymap entry in a specific mode doesn't override it. I think the reason why people add multiple keymap entries is because they want it to be there for only some modes, not every mode.

@deadpin You can already do that. Just add a keymap entry to the `3D View (Global)` section (or the `Window` section which is truly global). This will make it work in any mode, so long as a keymap entry in a specific mode doesn't override it. I think the reason why people add multiple keymap entries is because they want it to be there for only some modes, not every mode.

You can already do that. Just add a keymap entry to the 3D View (Global) section

Not quite, at least for 3D View (Global). Adding a custom keymap entry there doesn't work in Object mode (weirdly enough). It's why e.g. the Subdivision Set operator is duplicated for Object mode explicitly even -- 6 extra keymap entries that are nothing but clutter.

Setting at Window level seems like a workaround to a legitimate bug perhaps. Haven't tried it to see if it would work though I wouldn't want my keybinding to work while my cursor is over the outliner (operator shouldn't have to care too much about the region)

If folks are wanting to view multiple contexts at once, I wonder why if not to set the same key in multiple places more easily? All I'm suggesting is if that's really the case, we should fix that problem directly, instead of keeping the older list around (unless there's other reasons to do that)

> You can already do that. Just add a keymap entry to the `3D View (Global)` section Not quite, at least for `3D View (Global)`. Adding a custom keymap entry there doesn't work in Object mode (weirdly enough). It's why e.g. the Subdivision Set operator is duplicated for Object mode explicitly even -- 6 extra keymap entries that are nothing but clutter. Setting at Window level seems like a workaround to a legitimate bug perhaps. Haven't tried it to see if it would work though I wouldn't want my keybinding to work while my cursor is over the outliner (operator shouldn't have to care too much about the region) If folks are wanting to view multiple contexts at once, I wonder why if not to set the same key in multiple places more easily? All I'm suggesting is if that's really the case, we should fix that problem directly, instead of keeping the older list around (unless there's other reasons to do that)
Member

I think you've found a bug there. When I try working with the Subdivision Set operator in a global context all kinds of weird things happen. In fact the Subdivision Set operator seems to display unexpected behavior (to the user at least) even with the default keymap.

As to why you'd want a large list or to see multiple contexts at once is to get a better overview of whats there, not to mention that lists are easier to scan through than the visual keymap proposed here, and you can also have multiple keymaps open and editable at the same time. Another reason is that sometimes you can't currently just assign to a global context because you actually need a different operator for each context; an example of this is the select all operator. There are many different select all operators like object.select_all, mesh.select_all, curve.select_all, action.select_all, gpencil.select_all, etc. (spread across multiple contexts) that all use the same shortcut (A). Changing the shortcut for this operator is already hard, but without access to a list like we have now it would be much harder.

I think the improvements suggested here are useful, but I think there is still value in being able to work with the current list, so I don't think it should be removed, at least for now. As this progresses, solutions may be found that make the list view obsolete, but the current proposal doesn't account for the more complex situations.

I think you've found a bug there. When I try working with the Subdivision Set operator in a global context all kinds of weird things happen. In fact the Subdivision Set operator seems to display unexpected behavior (to the user at least) even with the default keymap. As to why you'd want a large list or to see multiple contexts at once is to get a better overview of whats there, not to mention that lists are easier to scan through than the visual keymap proposed here, and you can also have multiple keymaps open and editable at the same time. Another reason is that sometimes you can't currently just assign to a global context because you actually need a different operator for each context; an example of this is the select all operator. There are many different select all operators like `object.select_all`, `mesh.select_all`, `curve.select_all`, `action.select_all`, `gpencil.select_all`, etc. (spread across multiple contexts) that all use the same shortcut (A). Changing the shortcut for this operator is already hard, but without access to a list like we have now it would be much harder. I think the improvements suggested here are useful, but I think there is still value in being able to work with the current list, so I don't think it should be removed, at least for now. As this progresses, solutions may be found that make the list view obsolete, but the current proposal doesn't account for the more complex situations.

Added subscriber: @LeoSch

Added subscriber: @LeoSch

Added subscriber: @Schiette

Added subscriber: @Schiette

Added subscriber: @1D_Inc

Added subscriber: @1D_Inc

While Blender's keymap editor is very flexible, it isn't very easy to get a clear overview, to spot conflicts, or to edit in general.

This proposal provides key-oriented solution instead of operator-oriented.
Operator-oriented is good in editing in general, since it provide clear view of the entire operators structure per modes and the list of available assigned operators, and also can be filtered across modes.
I think proposed solution can be used as a layout viewer, since it prioritizes keys instead of operators, and even with that in mind you have to check all Ctrl Alt Shift combinations to get full key map image per single mode.
Maybe, adding Any button to the filter, that will expose all key's modifiers will help that.

Operators have too long names to fit buttons GUI, and writings like "Start" and "End" are are far from self-evident.
Also it is unknown how to be with things like that
изображение.png

изображение.png

In my opinion, Blender have too complex keymap system to be comfortably exposed in key-oriented way.

In #76678#932960, @deadpin wrote:
Why do I have to add/change the same keymap entry (key and action) for both "Object Mode" and "Mesh" today? What I really want is to add/change that entry for "Viewport" and have it apply to object mode and mesh accordingly.

Because they have different functionality. There is extrude operator in mesh mode and no extrude in object mode.

> While Blender's keymap editor is very flexible, it isn't very easy to get a clear overview, to spot conflicts, or to edit in general. This proposal provides key-oriented solution instead of operator-oriented. Operator-oriented is good in editing in general, since it provide clear view of the entire operators structure per modes and the list of available assigned operators, and also can be filtered across modes. I think proposed solution can be used as a layout viewer, since it prioritizes keys instead of operators, and even with that in mind you have to check all Ctrl Alt Shift combinations to get full key map image per single mode. Maybe, adding Any button to the filter, that will expose all key's modifiers will help that. Operators have too long names to fit buttons GUI, and writings like "Start" and "End" are are far from self-evident. Also it is unknown how to be with things like that ![изображение.png](https://archive.blender.org/developer/F8614276/изображение.png) ![изображение.png](https://archive.blender.org/developer/F8614280/изображение.png) In my opinion, Blender have too complex keymap system to be comfortably exposed in key-oriented way. > In #76678#932960, @deadpin wrote: > Why do I have to add/change the same keymap entry (key and action) for both "Object Mode" and "Mesh" today? What I really want is to add/change that entry for "Viewport" and have it apply to object mode and mesh accordingly. Because they have different functionality. There is extrude operator in mesh mode and no extrude in object mode.

@1D_Inc I don’t think that’s true. The current keymap editor is not really operator-centric at all. It doesn’t list all operators and then which keys are assigned to them - It just primitively lists all the keymap entries in a rather unsorted list. That’s not operator-centric.

@1D_Inc I don’t think that’s true. The current keymap editor is not really operator-centric at all. It doesn’t list all operators and then which keys are assigned to them - It just primitively lists all the keymap entries in a rather unsorted list. That’s not operator-centric.

@WilliamReynish Technicaly, true, it is not operators-centric, it is assigned operators-centric, since its a list of assigned operators, which allows you to observe operators by modes, including modal ones.

@WilliamReynish Technicaly, true, it is not operators-centric, it is assigned operators-centric, since its a list of assigned operators, which allows you to observe operators by modes, including modal ones.

Removed subscriber: @deadpin

Removed subscriber: @deadpin

Added subscriber: @L0Lock

Added subscriber: @L0Lock

This comment was removed by @L0Lock

*This comment was removed by @L0Lock*

Added subscriber: @brecht

Added subscriber: @brecht

@L0Lock, I'm afraid I have to remove your comment because of this:
https://lists.blender.org/pipermail/bf-committers/2020-July/050616.html

This content can't be posted on any of the Blender development websites.

@L0Lock, I'm afraid I have to remove your comment because of this: https://lists.blender.org/pipermail/bf-committers/2020-July/050616.html This content can't be posted on any of the Blender development websites.

@brecht then I'd rather just remove the screenshots from my post - eventually replace them with mockups at some point - but keep my comment alive.

@brecht then I'd rather just remove the screenshots from my post - eventually replace them with mockups at some point - but keep my comment alive.

It's not just screenshots that are not allowed, detailed explanation of the implementation in other applications should not be posted here either. You can write a new comment with just explanations of how you think Blender should work.

It's not just screenshots that are not allowed, detailed explanation of the implementation in other applications should not be posted here either. You can write a new comment with just explanations of how you think Blender should work.

Then can I have a copy of my original comment please ?

Then can I have a copy of my original comment please ?
https://pastebin.com/E60wPGtB

@L0Lock
Are you planing to reconstruct the entire post?
Maybe I am too early, but

This on itself would basically replace the need for addons that only consist of creating operators just to make new hotkeys.

No. This solution has a hard limit - usable keys are not infinte.
That's why such tools are used with spacebar menu and command alias, especially during repetitive linear work.

image.png

And let the advanced user make their own jam. And we all love that, don't we?

We are currently retraining such an "advanced user" to the professional wide-range modelling layout.
It is always painful, but necessary for productive teamwork.

@L0Lock Are you planing to reconstruct the entire post? Maybe I am too early, but > This on itself would basically replace the need for addons that only consist of creating operators just to make new hotkeys. No. This solution has a hard limit - usable keys are not infinte. That's why such tools are used with spacebar menu and command alias, especially during repetitive linear work. ![image.png](https://archive.blender.org/developer/F8734079/image.png) > And let the advanced user make their own jam. And we all love that, don't we? We are currently retraining such an "advanced user" to the professional wide-range modelling layout. It is always painful, but necessary for productive teamwork.

Are you planing to reconstruct the entire post?

Yes, but I need to rethink the entire thing and probably make my own mockups. It will take some time x)

By the way, are there some form of tool or asset pack to create the beautiful mockups we often see here? I'm sure the community would be happy to be able to use them too (and me). Unless it's programming a custom Blender build x)

No. This solution has a hard limit - usable keys are not infinte.
That's why such tools are used with spacebar menu and command alias, especially during repetitive linear work.

You show an example where there are existing operators to call. Any operator can be hotkeyable AFAIK, so creating a "custom command" for that would be useless since you can already hotkey the operator itself.
But what about this that don't exist as operators ? What about macros ?

I personally had to create scripts just to be able to bind things to my keyboard, like a key to reset all Stretch To constraints in my armature, another to Set Inverse all the Child Of, increase/decrease the gizmo size, ... Things I can't do with a search bar unless I first create the operators myself. They can be very user-specific, they can be temporarily, but if there's a way to at least make it easier, why not ?

> Are you planing to reconstruct the entire post? Yes, but I need to rethink the entire thing and probably make my own mockups. It will take some time x) By the way, are there some form of tool or asset pack to create the beautiful mockups we often see here? I'm sure the community would be happy to be able to use them too (and me). Unless it's programming a custom Blender build x) > No. This solution has a hard limit - usable keys are not infinte. > That's why such tools are used with spacebar menu and command alias, especially during repetitive linear work. You show an example where there are existing operators to call. Any operator can be hotkeyable AFAIK, so creating a "custom command" for that would be useless since you can already hotkey the operator itself. But what about this that don't exist as operators ? What about macros ? I personally had to create scripts just to be able to bind things to my keyboard, like a key to reset all Stretch To constraints in my armature, another to Set Inverse all the Child Of, increase/decrease the gizmo size, ... Things I can't do with a search bar unless I first create the operators myself. They can be very user-specific, they can be temporarily, but if there's a way to at least make it easier, why not ?

Added subscriber: @AlienTux

Added subscriber: @AlienTux

Added subscriber: @ionarn

Added subscriber: @ionarn

Added subscriber: @Nurb2Kea

Added subscriber: @Nurb2Kea

Added subscriber: @SHEK

Added subscriber: @SHEK
Philipp Oeser removed the
Interest
User Interface
label 2023-02-10 09:24:28 +01:00

So this is just dead?

So this is just dead?
Contributor

@Funnybob yes

@Funnybob yes
Member

Since it's a design task of an issue that didn't disappear in the meantime I'd call this "Inactive". Once this get's the needed development time, already having a design for it is a great start.

Since it's a design task of an issue that didn't disappear in the meantime I'd call this "Inactive". Once this get's the needed development time, already having a design for it is a great start.

When we tried to handle this task back in 2011 we found it incredibly challenging, close to mathematically impossible.

When we tried to handle this task back in 2011 we found it incredibly challenging, close to mathematically impossible.

When we tried to handle this task back in 2011 we found it incredibly challenging, close to mathematically impossible.

but Maya developers somehow coped with this challenge. why can't blender devs do this?

> When we tried to handle this task back in 2011 we found it incredibly challenging, close to mathematically impossible. but Maya developers somehow coped with this challenge. why can't blender devs do this?

When we tried to handle this task back in 2011 we found it incredibly challenging, close to mathematically impossible.

but Maya developers somehow coped with this challenge. why can't blender devs do this?

It's not the opinion of Blender developer that this is "mathematically impossible", that's @1D_Inc opinion which I don't think is based on a deep understanding of the implementation. It's a matter of having significant time to dedicate to it. A challenge is that the Blender keymap is much more customizable than e.g. Maya, so making a good high level UI for it is not easy. But there are ways to solve that with enough time.

> > When we tried to handle this task back in 2011 we found it incredibly challenging, close to mathematically impossible. > > but Maya developers somehow coped with this challenge. why can't blender devs do this? It's not the opinion of Blender developer that this is "mathematically impossible", that's @1D_Inc opinion which I don't think is based on a deep understanding of the implementation. It's a matter of having significant time to dedicate to it. A challenge is that the Blender keymap is much more customizable than e.g. Maya, so making a good high level UI for it is not easy. But there are ways to solve that with enough time.

The problem is that Blender's keymap setup is much more flexible and context-rich to be represented in such simple form like it was made later in Maya.

In system design the problem of a flexibility/manageability tradeoff is pretty common.

High flexibility implies low manageabiliy and vice versa - high manageability implies low flexibility. The system design process assumes reaching some balance between them.

When Blender hotkeys system was originally designed, a higher flexibility level than in Maya was supposed to be supported.
As a result, wrapping Blender's system into Maya's shape is similar to trying to pour 3 liters of water into a 2 liter bottle.

Our studio put lots of time and efforts to design possible solution to this problem though, but we didnt reached stable result to propose to the core developers.

The problem is that Blender's keymap setup is much more flexible and context-rich to be represented in such simple form like it was made later in Maya. In system design the problem of a flexibility/manageability tradeoff is pretty common. High flexibility implies low manageabiliy and vice versa - high manageability implies low flexibility. The system design process assumes reaching some balance between them. When Blender hotkeys system was originally designed, a higher flexibility level than in Maya was supposed to be supported. As a result, wrapping Blender's system into Maya's shape is similar to trying to pour 3 liters of water into a 2 liter bottle. Our studio put lots of time and efforts to design possible solution to this problem though, but we didnt reached stable result to propose to the core developers.

So would it be possible to make a compromise? Instead of having a full fledge keyboard editor à la Maya, just make a simple interface that would display a keyboard and mouse and highlight which combinations are already taken or not? Without the possibility to actually assign anything. Just a display.

So would it be possible to make a compromise? Instead of having a full fledge keyboard editor à la Maya, just make a simple interface that would display a keyboard and mouse and highlight which combinations are already taken or not? Without the possibility to actually assign anything. Just a display.

As far as I know, the community also has not moved beyond the IsKeyFree addon functionality in this area.

https://docs.blender.org/manual/en/latest/addons/development/is_key_free.html

As far as I know, the community also has not moved beyond the IsKeyFree addon functionality in this area. https://docs.blender.org/manual/en/latest/addons/development/is_key_free.html

Oh! How come I never heard of this addon? Anyways, it does the same thing as searching in the keymap editor and it's actually better in the keymap editor because it's not just an endless list of text. What we need is the complete opposite. I want a tool that will visually show me what is taken/available. This will only show you what is taken.

Oh! How come I never heard of this addon? Anyways, it does the same thing as searching in the keymap editor and it's actually better in the keymap editor because it's not just an endless list of text. What we need is the complete opposite. I want a tool that will visually show me what is taken/available. This will only show you what is taken.

Back in the 2.5 days we also had the System Keyboard SVG Addon, which generated SVG vector images on the current keymap setup.

Addon_keyboard_layout.png

I don't think these were ever very useful, beyond the novelty factor, or occasional printing a cheatsheet, judging by how unknown and unmaintained it remains today.

I'd say developer efforts would be better spent improve the current editor in other useful ways, like better importing/conflict resolution, batch editing of entries, reordering, persistent "sticky" headers, conflict warning etc.

Back in the 2.5 days we also had the [System Keyboard SVG Addon](https://github.com/blender/blender-addons-contrib/blob/main/system_keyboard_svg.py), which generated SVG vector images on the current keymap setup. ![Addon_keyboard_layout.png](/attachments/6e1e178c-eb08-44ba-bfbc-b47d577f944c) I don't think these were ever very useful, beyond the novelty factor, or occasional printing a cheatsheet, judging by how unknown and unmaintained it remains today. I'd say developer efforts would be better spent improve the current editor in other useful ways, like better importing/conflict resolution, batch editing of entries, reordering, persistent "sticky" headers, conflict warning etc.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
22 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#76678
No description provided.