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.
2 Likes
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:
- It seems to frequently be the case that if I want to change 1 hotkey, I also have to change 10 or more additional hotkeys, which can quickly cascade into my needing to change LOADS more.
- When I change a hotkey to one that conflicts with the hotkey assigned to another function (switch scale to “r” for example if you want to test this), blender gives zero indication that there is a conflict, much less any easy means of resolving it.
- Related to #1 - If I want to change the hotkey for “move/translate” to “w” for example, I want to do so for all analogous cases where a “move/translate” function would be used, such as when moving UV islands. We need a way of visually grouping and mass editing the hotkeys for analogous functions.
- There are many command entries that look identical and it’s difficult to discern what does what.
5 Likes
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:
- Blender starts
- Base keyconfig loads, whatever that is (Blender Default, Industry Standard, etc)
- Addons are loaded one by one
- if it has a default key config, load it and automatically handle downstream conflicts
- User keyconfigs loads additively. ONLY the keys they bound are in this config which makes it portable and easy to modify/maintain. Ideally you could have any number of user keyconfigs to layer up for different roles. Again, any downstream conflicts in Addons or Base should be handled automatically.
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.
2 Likes
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?
not a lot of time to reply- but briefly: Blender has a very high ceiling when compared to a lot of other mainstream apps. There is a lot of market consolidation happening (with regard to tools) and as that happens the companies that make those tools are less incentivized to innovate or improve. So while they have a huge head start in terms of reliability and adoption, that lead is unlikely to last without some major push to keep up with Blender’s rate of growth. I think with 2.8, Blender crossed an inflection point in the hearts and minds of professional artists so we’re going to start seeing a snowball effect where more people try it out and stick, some of them contribute to the dev fund or help improve future releases, or tell their colleagues (which perpetuates the cycle).
So while Blender might not be there quite yet, it’s visible on the horizon, meanwhile Autodesk seems to be pulling into the breakdown lane.
For me personally (having a strong technical background), it’s the robust Python API. All of the problems that I mentioned above I was able to solve for the artists at my studio because of a Python API that gives a technical artist or programmer plenty of rope to hang themselves with. Yes, it sucks that any of that work was necessary- but the fact that it could be solved in the first place without having to break open the source code is nothing short of amazing. Combine that with the high growth potential of Blender and you can imagine a lot of new technical types coming to Blender and bringing new functionality with them. Addons like HardOps and MeshMachine are already way ahead of the bleeding edge for modeling- Maya scripts and plugins aren’t able to keep up.
I could go on, but that’s a pretty good summary for the time that I have 
2 Likes
Just wanted to mention a proposal I made on RCS for being able to manage the keymap more easily…
Also, since you guys seem to closely understand what causes problems with the keymap, I have a problem with the Sidebar and the Toolbar, in the 3D View, lagging when opening / closing them, and having the Navigate Viewport Overlays getting stuck and not coming back when closed. That behavior is related to the customisation of the Keymap (Userprefs file). At some point when customizing the keymap, this lagging started to happen. I had this problem with 2.80 and 2.81, and now I finished remapping a completely new keymap fresh from 2.82 and it happens again.
Do any of you guys have this problem? I’ve made a thread about it here:
Thanks for your reply testure. HardOps and MeshMachine are among the major incentives that have driven my interest from a modeling perspective. Despite my misgivings I’m going to continue exploring blender generally and those addons in particular.
Unfortunately all of you seem to be focused in introducing means of managing the mess current keymap system is. That’s just no way to go. Creating layers of abstraction just sweeps it under the bed, but the reliability and complexity issues will still be present.
My original post was that currently the keymap editor is broken to a degree that some changes can result in keymap corruption. Because of this, one is forced to edit keymap manually by editing the .py file, but this has been made much more difficult by the new formatting which makes the keymap much less human readable.
But ultimate solution to the keymap issue would be having ONE GLOBAL KEYMAP for all the editors, with more abstract concept such as for example “Select Row” and “Select Column” which would be then mapped in individual editors, for exmaple in 3D editor as select loop and select ring, in curve editor as select all keyframes on a curve and select all keyframes on current frame, etc… So that assigning one global hotkey to for example zoom to selection would propagate this to related functions in all editors.
Then, optionally, one would have an option to override these on local editor level, for keys which are too specific for the given editor. But any editor features which are shared by more than one editor (or have similar equivalents in other editors) would have global hotkey. This would leave absolutely no space for duplication.
Any attempts to just take current messy unstable system and build something on this broken foundation will probably make things only worse.
1 Like
sounds like you need to find a solid repro case and log a bug, I have never experienced the degree of ‘corruption’ you’re describing. All of the issues I have had and have seen at my studio are related to the user experience (or lack thereof). Users do not get the results they are expecting so they keep messing around in the keymap editor essentially breaking things- but the data itself is not corrupted. It’s exactly what it says it is. your solution seems to be ‘change the keymap file format back to a human readable form’, which is the antithesis of a good user experience. The goal should be to fix the design of the editor so people don’t have to edit the file in the first place.
I did file 3. They were either ignored or cleaned up onto some todo list that is long forgotten.
Here is something that I find bugy.
When you expand some of the key settings, the moment you change one of the key commands everything collapses and the change you made goes off screen somewhere.
do you have a text filter set? if you’re searching for something and then change the operator idname to something that no longer matches your search it will disappear. While this is not technically a bug I would say that it is definitely undesirable behavior, and probably a design issue or papercut.
I only see two, one was resolved with a patch. The other was closed as invalid because it’s not a bug- but a feature request with an existing workaround. And the TODO list you mention isn’t long forgotten, it was triaged as recently as December.
In this case no, it happens without using the search.
That’s actually one of those bugs I’ve reported that likely ended up ignored.
I know that there is a search field but I hope that one day, there would be an option (a checkbox) to sort hotkeys in alphabetical order:
3 Likes
That won’t work as there are some operators which are dependent on a proper vertical order.
somebody has some scripts with hotkeys working? when deleting a key from addon preferences, without saving nothing, an error appears on next restart. "Traceback (most recent call last):
File “D:\DD-profil\Telechargements\Compressed\blender-2.90.0-59b523c3c98e-windows64\blender-2.90.0-59b523c3c98e-windows64\2.90\scripts\startup\bl_ui\space_userpref.py”, line 1813, in draw
if search not in info[“author”].lower():
AttributeError: ‘tuple’ object has no attribute ‘lower’ "
you can delete startup.blend, usepref.blend, key config save, the problem remain untill a new version of blender. if you do the same on a new version same thing…
I searched for working hotkeys config for one year
if you do an addon you won’t impose your own general key config…
same thing how to modify an existing key and install a new one at the same time. everything I tried ends not working after some modifications…if you want to do a pie menu with drag over an existing key, you need to modify it from press to click… 2.7 script working 2.8 big mess
init.txt|attachment (8.4 KB) example. in this one you can’t delete the key from addon preferences but if you do it directly from key in preferences the same problem appears that in my script. I tried a lot of repo on github search for a lot of help. I did my own version version a little simpler that here. same pb.