2.8 keymap file formatting mess

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 :slight_smile:

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.
keymap_editor

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.