Hi,
I am curious why keymap file formatting in 2.8 is so messy. Blender’s keymap editor suffers from quite a few completely destructive bugs that make it very risky to edit keymap within Blender’s keymap editor. I was only able to successfully create my own custom keymaps without any corruption and data loss by editing the .py file outside of the blender.
2.8 however makes it much more difficult by formatting the keymap files in much less readable manner:
Why…?
I agree.
The difficulty I have is that there isn’t any good documentation on how to setup an external Python file. I’ve used HeavyPoly’s hotkey script as a guide, but I don’t know of a way to disable default keys, which is essential to me (I disable ‘B’ for Box Select every time). His method seems to only append new keys to the keymap.
So? Any response on this?
Since fixing all the corrupting bugs in the keymap editor was refused for being out of scope of 2.8, the very least that could be done is at least not make life significantly harder for people who want to customized they keymap without randomly getting all their work lost. 
The file format was changed from a Python script to a structured format that does not break when one operator or operator property gets changed or removed.
If you want to manually edit the keymap Python file, a better starting point would be the default Blender keymap:
https://developer.blender.org/diffusion/B/browse/master/release/scripts/presets/keyconfig/keymap_data/blender_default.py
Uh, I don’t think we understand each other. What’s in my original post is the screenshot of how blender 2.8 saves the default blender keymap. That is the default blender keymap on the left. The problem is that it’s saved with a formatting that is significantly less human readable than how it got saved in 2.79.
I understand, the new key configuration file format was not really designed with readability as the main priority, but it could be improved.
I’m just saying that if you want a solution now, using the blender_default.py I linked will give you a readable format of the 2.8 keymap to customize.
Oh, I see. Well, I am afraid I am already way too deep in it now to start back from scratch. I will see if I can at least use some pieces. Thanks.
It’d still be better if the keymap corruption bugs would be solved so that one would not have to customize keymap by editing .py files in the first place 
I’m not sure exactly what you mean by keymap corruption bugs, are those in the bug tracker?
Some of them yes, such as:
https://developer.blender.org/T55012
https://developer.blender.org/T53710
There are a few more, which randomly delete keys, but I kinda gave up at reporting them, since one got cleaned up into obscure TODO no one will check again, and other one was not reproduced despite being very easy to reproduce.
The three main bugs that are currently most dangerous are:
1, Removing some of the keymap input entries will result to some others removed on keymap re-import.
2, Some keymap entries are order dependent, but the keymap editor has no means of reordering the entires.
3, When you create key binding of same operator mapped to same hotkey, as soon as you do, both new and original keybinding will disappear, destructively, without any way to undo, so you have to roll back to last saved exported map.
Here’s an example of #1,
If you delete some of the keymap entries using the [X] button, then proceed to export the map, and then reimport it again, it will actually delete quite a few more entries which were assigned to same/similar operator, but different keys. If you click restore, you will gain those key mappings back, BUT if you do not notice it, even once, and proceed to export the keymap again, those key bindings will get deleted forever.
So all it takes is to forget it even just once, and you may lose up to hours of work, by having a keymap that’s missing many of the keybindings because you’ve deleted some of the remotely related ones.
EDIT: Forgot breaking bug #4
If you export keymap with nothing in the viewport selected, there is a random chance that the properties of set object mode operator in object non-modal categories will get wiped, effectively disabling those key bindings:
So I have to periodically re-set them save again and hope they stick.
I appreciate you posting this, but as someone that has been extensively editing the file Blender creates when exporting the keymap (the one Rawalanche is complaining about), this is more difficult for me to understand.
I do hope this post is taken into consideration when work is done to the keymap editor. Having an easy read/edit external file is great when traveling, using a new computer, or needing to reset User Prefs/Startup file. I know I’ve seen sharing keymaps get poo pooed because they can be very specific to one person, but I’ve learned A LOT from studying other peoples keymaps.
To go with the file Rawalanche is using, theres:
kmi = km.keymap_items.new
Which creates a new entry. This is fine, but I’d also like to see:
kmi = km.keymap_itmes.remove
kmi = km.keymap_items.disable
kmi = km.keymap_items.edit
This way I can easily edit my keymap in an external file that’s easy to read. I know both Heavypoly and Machin3 use external files like the one Rawalanche is using.
I understand what you are saying, but the way on the right side is actually less organized in terms of machine readability.
The format on the left is easily readable by code. And I suspect the devs are working on a new keymap editor to give this change a perfect meaning.
The issue is that right now, the keymap editor is such a minefield that only reliable way to edit keymap is manually inside the file. So until keymap editor is fixed, I think that human editability has priority over computer readability.
I can’t wait any seconds longer for the Devs to reveal to us the better keymap editor. I don’t really know why out of all the UI improvements, Keymap editor barely got any.
I hope we get to see how it goes soon.
I can only second the opinion that this part of blender really needs work. Customization is a great strenght in Blender but the way it is handled at the moment leaves much to be desired.
The entire structure of the keymap editor could be improved a lot. Finding shortcuts is sometimes really cumbersome. In addition there is no real warning when assigning shortcuts that are already used and interfere with the new shortcut… which is problematic in itself as a new user learning the program like me can inadvertently disrupt functions not even knowing it.
What drives me insane currently however is that Blender in its latest Builds does not load my keymap properly. in order to to get my proper keymap I have to manually load the industry keymap and then load my file or pick my saved setup. Otherwise it seems to revert to Blender default mixed with my keymap so my custom shortcuts work but simple things like sub object modes 1,2,3 don’t.
Honestly if you are doing a really complex keymap, I would not do it in the Keymap editor UI. It’s much easier to edit the .py files for either the default or Industry Compatible keymaps.
The only reason it’s easier is because keymap editor is broken and buggy. If that was not the case, there’s absolutely no question editing keymap via the UI would be much more efficient.
I have the same exact problem: I continue randomly losing key assignments in my customized keymap; more in depth, I change a shortcut and save as default and also export to a personal folder but after few more keymap adjustments and subsequent savings, I loose some previous assignments. And worst of all, it strikes randomly on my keymap so I periodically find bad surprises.
I need to put my two cents in here. It’ll be a bit long, but hopefully what I have to say will raise the subject of the keymap editor to a level of much greater importance.
I’m coming to Blender just now from a long background in Maya working for VFX and animation studios. The reason I’m looking into Blender right now is that at the studio I work for we’ve been discussing how we want to do things in the future and several of us feel that blender has some very interesting features which could fit in nicely with or even replace some of our existing tool-set. At the moment we are mostly looking at it as a solution for modeling/lookdev/lighting with lookdev and lighting handled via gaffer from image-engine (https://www.gafferhq.org/) which has just started implementing cycles. We expect to move our way into this slowly, beginning with some tests to see how easy it would be to do lookdev and lighting directly in blender and gaffer, what the results are, etc. But, I’m also looking into it as a modeling solution and thus far the major roadblock I’m coming up against is hotkeys and the keymap editor.
Now, many blender users will say “get off your lazy elitist butts and learn new hotkeys”, but I need to point out to you how impractical that is from a studio perspective. Blender’s default hotkeys and tool functions are VERY different from Maya’s and while some of them can be adapted to fairly quickly others most definitely cannot and many are in fact much less efficient for the average, if not all, users to use. The problem is that the VFX and animation industries are very transient. We are frequently staffing up, and then down, bringing in new artists all the time, and when we do we need to be able to draw on the biggest and best pool of artists available - which in our segment of the industry mostly means Maya users - and to have them moving at speed right away. Unfortunately, the amount of time that would be required to get the average artist ramped up on using blender poses a serious challenge to our ability to do this in the timeframes we have and at an effective cost (the saving’s from using blender rather than paying for Maya could very quickly be eaten up in lost productivity).
Now, yes - I know about the industry compatible keymap and it certainly makes a big difference at first blush. As does FORMAFFINITY’s “Maya Config Addon For Blender 2.8” btw (https://gumroad.com/l/FKhQL) (the marking menu and camera pie menu’s make a HUGE difference). But - they are buggy. I’ve already encountered various instances where the keymaps from both of these sources result in other tools being broken (tweak selection for example when using the industry compatible map) and there are cases where I actually prefer the blender defaults, plus, blender has a different tool-set that requires a different prioritization of hotkeys, utilizing the easiest one’s to execute for the most common tasks, etc.
All of this amounts to the need for studios and individual artists to be able to efficiently edit the keymap. Unfortunately, that’s pretty much impossible with the way the keymap editor works right now and that might be a deal-breaker for us, at least with regards to modeling, which means, btw, that it’s also a huge obstacle for blender acquiring a wider user base - especially among working professionals.
I will point out just a few of the challenging aspects of editing the keymap:
My studio has been using Blender for a long time now and can completely agree with all of these points. Such that I had to write some very complicated python scripts to handle a lot of this work for us. I have scripts that check for downstream keyconflicts (which necessitated creating a keymap ‘lineage’ to even know what a conflict was), which means I also have to track all of this data in case a user wants to remove a custom keybind (and have the default conflicts restored). Before this, we had so many users not understanding that their hotkey wasn’t working because they mapped it to “3D View”, which was correct, but a keymap item in “Mesh” was taking priority. Additionally, I solved your issue #3 by creating a system of ‘key aliases’ that my keybind system maps to all the various places that type of functionality is used. It’s a HUGE mess and took me ages to get serviceable (it’s still not perfect, but works for most cases).
In addition to your complaints I would add a few more that you may not have run into yet that are VERY real problems for large studios:
There is no concept of additive keyconfig loading. You have a keyconfig, and it has all of the keymaps and keymap items for that config and that is it. This means that for every role in your studio you need a very hard to maintain keyconfig with hundreds of bindings that are unrelated to that role but must still be included in order for basic functionality in Blender.
Other software handles this by using additive keymap loading. A base config is loaded, and then how ever many additional layers you need afterward- each one taking precedent over the last.
All addon keymap items are just dumped into a gigantic “addon” keyconfig with no way to tell if that addon has any custom keybindings, and if so what they are or how to change them. For example- If a user wants to use the F2 addon, but they don’t use the F key to fill polys, they have to track it down in the keymap editor (some addons bind many keys in different keymaps). Addons can name their operators whatever they like, so some are even disguised as built-in operators! view3d.not_a_real_op() could be sitting right next to view3d.select().
The solution for this is to give each addon its own keyconfig and allow users to modify that keyconfig within the context of that addon (so, in the addon preferences). Some addons have taken it upon themselves to do this work (the addons I’ve written for my studio, hardops, machinetools, etc). But most do not because it is an extreme amount of effort. I can’t exaggerate this, my custom keybinding code is at least half the size of my entire studio scripts package and that’s just to get a tolerable user experience up and running.
Ideally, Blender’s key config works something like this:
As for user experience, Addon keymap items should be in the preferences for that addon and stored in a separate config specifically for that addon. If the user changes a keymap, downstream conflicts should be automatically resolved by deactivating those bindings and informing the user that they were disabled.
Thanks for sharing this. I wish I could say it was encouraging:) Unfortunately it only deepens my sense that adopting blender as a modeling solution is an impractical course of action for us until this issue is resolved.
I really hope the blender devs take this issue very seriously. This really might be the #1 barrier to adoption that blender now faces. Everything else that they are working on is important too, but none of it will matter if most teams like ours conclude that it is too much trouble to adopt blender because it’s such a pain to make it work in a way that suits our needs.
If I had a say in blender’s development roadmap I’d make this the first priority: make the blender user experience extremely flexible and easy to change so that people can quickly and fully adapt it to their preferred workflow. This mostly applies to the keymap - and if that alone were fixed it would probably be enough, but it also applies to the ability to re-arrange the UI. The 2.8x release comes with a HUGE UI improvement, but still falls short of what we have in other pro software where we can detach and drag and drop panels to re-arrange them on the fly.
And BTW - this would benefit everyone, including existing blender users.
P.S. - @testure, can you share with me how your studio is making use of blender, and whether you feel that what it brings to the table justifies the work you’ve put into making it usable?