Industry Compatible Keymap: Questions, suggestions and answers

@sakana3 Hi Sakana, take a look here:

1 Like

I can reproduce the issue with Shift-clicking, but I don’t understand why it doesn’t work. I’ll try and investigate.

1 Like

Ok yes, you are right - sort of. There was an entry for the Scale Cage tool, which in practice wasn’t assessable because Shift-R would set Scale keyframes, and now it’s not necessary due to the cycling working when you repeat the tool key shortcut. The shortcut for Scale Cage has been removed now.

Btw, now the tooltips properly show the shortcut key for cycling tools:

Screenshot 2019-12-12 at 11.25.10

The problem seems to be that the Gizumo display does not update when the modifier key is pressed. I found that not only PolyBuild, but also all tools no longer highlight Gizumo.
The same goes for add-ons. For example, the same symptoms can occur with the standard “Snap _ Utilities _ Line”.

Yep, I can confirm. In edit mesh mode click on the knife tool, then press alt+c for loop cut. The mouse cursor is still a knife.

That was fast. Cool.

As I am still a bit into tweaking my own custom keymap. I found some more points worth changing for everyone using this keymap. I hope you can agree.

  1. There is little inconsistency in the different EditorTypes fot the View Frame Function. Most rely to Numpad 0 like the blender keymap but the GraphEditors View Frame is set to Shift+A. I’d change that back to Numpad 0.

  2. Another Shift A is used in 3d-view für View All for All Regions
    I’d remove that completely as it’s not much needed and just works with quadview and at least currently not at all with multiple 3dviewports (but would make sense). So I’d say the view menu entry is enough for that.

  3. What I’d propose is to set the new Mask Expands to Shift+A and Alt Shift+A for Sculptmode as it is also in the Blender Keymap. They can’t be triggered from the menu in a way that makes sense, because the mouse position at the moment of triggering is the initial selection start point. No need to think about other shortcuts than blenders default-keymap ones here. They fit nicely to the IC KeyMaps Ctrl+A and Ctrl+Shift+A.

  1. As we already discussed OpenVDB Remeshing on Ctrl+R would be really nice.

  2. Perhaps we could also introduce some Shortcuts some of the other stacked icons in the mainbar aswell, at least for the two slide tools would be cool.

@Oskar, @sakana3, @billrey

Yes I can confirm that knife tool problem too, the second tool switch has to be done with the keyboard shortcut as hovering over the vertical toolbar leads to an updated cursor

Not sure if this relates to the PolyBuild tool problem. I haven’t tried regularly, but I am pretty sure I never saw it really working with the ICKeymap til now.
At least in my case a lot of the tool isn’t working as expected under IC Keymap:

  • The visual previews don’t work

  • Deleting faces doesn’t work at all (Shift+LMB)

  • “Face At Cursor Move” doesn’t work (Ctrl+LMB)

  • It’s just the “Extrude at Cursor Move” that works

I don’t follow this. Frame Selected is F and Frame All is A.

It’s been like this already for a while.

No idea what ‘stacked icons in the mainbar’ are.

I am not talking of frame selected, i am talking of “View Frame”.

Strange. It was definitely not working. Perhaps the prebuilt version I had installed was a day or so too old. Can’t reproduce it anymore as I’ve updated meanwhile. But it’s there now. You are completely right. Sorry if that caused inconveniences. Thanks.

Edit: My post and your commit with the remeshing shortcuts were both on 12th December. So it very likely wasn’t in the downloadable build that day.

Oops accidently typed the wrong word, sorry didn’t reread it, wanted to say toolbar ( the vertical one in the 3dviewport). I think especially things like vertex slide and edge slide and the two rip tools would benefit from cycling shortcuts.

stackedicons

Thank you and have a good weekend! :slightly_smiling_face:

@billrey

Blender 2.82 Alpha December 15, 00:23:19 - dfe965bee24d - Windows 64bit build

2 wrong mappings for Context Menu in Sculptmode ( RMB and Keybord ContextMenuKey) - IC Keymap (it’s working with Blender keymap)
due to mapping to wm.call_menu instead of wm.call_panel with Name: VIEW3D_PT_sculpt_context_menu

Edit: Now I see this also happens in Texture Painting Workspace , so you better check all recent changes to the context menu mappings you commited.

Hi @billrey. The Skin_Resize is a thing that would be great if it could find it’s way into this keymap. Ctrl+Alt+R could be a good shortcut, thats free in edit mode, that makes it related to the scale shortcut.

( ID: transform.skin_resize )

Perhaps it could also be added to the vertex context menu to make this feature more discoverable.
Btw. is there another mode available/planned for skin_resize so we could switch to that mode permament, like the other transform tools ( move,scale,rotate)? It could get an icon and put next to scale and scale_cage.

Is there any reason that the view menu still remains in poor state even after such a long time?
image
The rarely used direction such as bottom still occupies main angles while frequent ones like Front are present in awkward diagonal angle.

On top of that, the view menu contains view selected entry which is already mapped to F key while at the same time lacking Perspective/Orthographic toggle which currently has no key in this keymap.

Just swap positions of Front and Bottom and replace view selected with Perspective/Ortho toggle and it will actually become usable.

Also, Alt+C activates some weird version of Loop Cut where mouse wheel doesn’t change amount of cuts and the highlight is jagged and not antialised, while right click context menu activates the tool of very same name, but mousewheel cut count adjustment works and the highlight is antialised.

1 Like

Alt + C does nothing here, but yes, the highlight of the loop cut active tool is kinda more thick than the one from the modal loop cut tool… Weird…

None of those things are related to the keymap.

Sure, and when reported as a bug these days, they will not be considered a bug either. So basically let’s just leave it sucking forever, right?

1 Like

The pattern is always the same. Everyone on the dev team always rushes to be the first to escape any responsibility. Everyone just loves to say “it’s not technically my problem”, regardless of if they actually can do something about it or no. Everyone strives to have as little ownership of anything beyond their ultra narrow pool of responsibilities.

Technical interpretation: Is the view pie menu data stored within the keymap .py file? No.
Practical interpretation: Has the sub-optimal view pie menu layout negative impact on the usability of the keymap which maps it on one of its own keys? Yes.

Technical interpretation: Is the loop cut tool data stored withing the keymap .py file? No.
Practical interpretation: Has the sub-optimal loop cut tool behavior negative impact on the usability of the keymap which uses this version of the tool as primary means of performing cut operations? Yes.

With this kind of behavior, refusal to take responsibility for anything except the bare minimum, the progress in the area of Blender’s usability will always be equally as slow as it is now.

2 Likes

@billrey Great job on the keymap so far.

Using the January 4 version of 2.82, while “1” “2” “3” work for vertex/edge/face selection in the UV Editor, they don’t work when sync mode button is enabled in the UV Editor.

I can get them to work if in the keymap editor section Image > UV Editor > UV Editor (Global), I add three entries for mesh.select_mode for vertex(1)/edge(2)/face(3) BEFORE the four Context Set Enum entries.

If I add the three mesh.select_mode entries AFTER the four Context Set Enum entries, they won’t work, so they need to come before.

1 Like

Indeed - will fix that.

Recent fixes:

  • Polybuild tool fixed
  • Properly support GP Edit Mode
  • Support the recently added Drag option
  • Support 1-3 keys in the UV Editor when Sync Selection is enabled
2 Likes