My only concern with the marker-area approach for the time scrubbing thing is that it'll get a bit yucky when there are markers present (i.e. all the selection ambiguity problems). That said, Da Vinci Resolve does something similar (except AFAIK it doesn't have the markers to cause conflicts). It's also still more flexible this way than restricting to only click-dragging the line itself.

@Joshua Leung (aligorith):

Thanks, but as far as I can see, bpy.ops.anim.keyframe_insert() only works if you have keying sets enabled?

I also tried simply assigning keys normally to the items inside the keyframe menu, but that doesn't work. So that's why I went with this somewhat odd workaround.

If you can show me a better/simpler/more straight forward way to make it insert keys directly, I'm happy to use it instead.

@Joshua Leung (aligorith):

re. the marker area, we could make it a lot more obvious by doing the following change to move it to the top and also to make it more obvious:

If this is done, I think we should use the same approach in the built-in default keymap too.

It would be simply fantastic if you could help out with the above change. I think you are the one who knows the code for the animation editors the best. :)

• Step 1: Move marker area to the top
• Step 2: Make it always visible and more visually prominent
• Step 3: Move the frame numbers from the scrollbar to this area
• Step 4: Make the scrollbar thinner to match other areas

@William Reynish (billreynish) IIRC, you can use the type argument to it too.

For example, the following works on the default cube:

bpy.ops.anim.keyframe_insert(type="Location")
...
bpy.ops.anim.keyframe_insert(type="Rotation")

@Joshua Leung (aligorith) When I use that operator inside the keymap, it fails and complains that there is no keying set. Maybe it's to do with the keying sets being initialized after the keymap?

I'll keep the workaround until I can get the simpler solution working properly.

@Campbell Barton (campbellbarton)
Thanks for review. I'll look at your points.

Currently, to support Cmd and Ctrl, I am using params.ctrl_or_cmd in places where it will use either. This is then set to "ctrl" or "oskey" via a check in the template at the top.

Your method seems a lot more complex - would you prefer I use your method instead?

This issue with params.ctrl_or_cmd is - as I understand it, not a general solution we can apply everywhere because there are times both are expected to be used.

If it was generic - we could go with that. Otherwise, having a single location that gives us both makes it a lot easier to maintain, even if later on we do something more sophisticated,
it allows everyone to work on the same keymap without duplicating anything - or having users of one platform breaking things for others.

When there is too much copy-pasted code it's hard to avoid things getting out of sync by accident - and it takes extra time even if we manage to do it.

for now I think an automatic duplication is a quick way to have the new keymap maintainable with minimal fuss.

Then we can simply state:

For this keymap Ctrl and Cmd are interchangeable

No need to document every detail about when it is/isn't shared.

Later on we could handle this on an event handling level for eg.

@Campbell Barton (campbellbarton) Ok I might try your method. One question: Will it make it so the Cmd-key is displayed in the menus? For that to work, I think the Cmd ("oskey") shortcut must be placed before the Ctrl equivalent.

Currently, as it works here, the Cmd-key is shown in all the menus if on a Mac. On Win/Linux it shows Ctrl instead.

There may be a few places, as you point out, where shortcuts are entered twice, both with "oskey"and "ctrl", but those are inherited from the default keymap. I pretty much mostly am using params.ctrl_or_cmd in order to make sure entries are not duplicated.

We completely agree it's best to not have entries be duplicated, which is exactly why I added the params.ctrl_or_cmd template, which is used throughout the keymap.

I can de-duplicate those remaining instances, and either make them use params.ctrl_or_cmd or go with your method, even though I'm still not exactly sure what the advantage or the more complicated solution is.

Is there a reason why params.ctrl_or_cmd is bad, and your solution is better? Doesn't your solution get the same result, but using more code that seems more complex? Or is there something I am missing?

I can de-duplicate those remaining instances, and either make them use params.ctrl_or_cmd or go with your method, even though I'm still not exactly sure what the advantage or the more complicated solution is.

Sounds good.

Is there a reason why params.ctrl_or_cmd is bad, and your solution is better? Doesn't your solution get the same result, but using more code that seems more complex? Or is there something I am missing?

No, if it's a general solution that can be used everywhere - it's fine. I assumed it wasn't used because both existed in many cases.

There is a small down-side that we can't copy-paste keymap items between this and the default (without find-replacing 'ctrl'), but I don't consider that a deal breaker.

I didn't look closely at the implementation, but I'm fine with this being committed early and improving it incrementally.

In D4626#105085, @Campbell Barton (campbellbarton) wrote:

There is a small down-side that we can't copy-paste keymap items between this and the default (without find-replacing 'ctrl'), but I don't consider that a deal breaker.

We can add params.ctrl_or_cmd to the default keymap and always set it to ctrl perhaps. Also makes diffing the two files less noisy.

I could also just adopt Campbell's method if you guys think it's a better solution. I'm not wedded to using params.cmd_or_ctrl - it was just the best (only?) solution I knew how to do without adding hundreds of duplicated entries.

Would prefer to do this in one place compared to having params.ctrl_or_cmd everywhere. - it's verbose and we may remove if the event system can handle it (similar to middle mouse button emulation).

@Campbell Barton (campbellbarton) If I wanted to tweak the keymap for the actual transform gizmos themselves, how would I go about that? Are they able to be defined in a keymap?

For example, I would like to remove the Shift-clicking on the Move gizmo handles to constrain on the other axes, but using it for extruding instead.

Activating the keymap has the following warnings:

Warning: property 'action' not found in keymap item 'CLIP_OT_graph_select_box'
Warning: property 'action' not found in keymap item 'CLIP_OT_graph_select_box'
Warning: property 'next' not found in keymap item 'SCREEN_OT_frame_jump'
Warning: property 'next' not found in keymap item 'SCREEN_OT_frame_jump'
Warning: property 'next' not found in keymap item 'SCREEN_OT_frame_jump'
Warning: property 'next' not found in keymap item 'SCREEN_OT_frame_jump'
Warning: property 'release_confirm' not found in keymap item 'OBJECT_OT_duplicate_move'
Warning: property 'release_confirm' not found in keymap item 'MESH_OT_duplicate_move'
Warning: property 'release_confirm' not found in keymap item 'CURVE_OT_duplicate_move'
Warning: property 'release_confirm' not found in keymap item 'ARMATURE_OT_duplicate_move'
Warning: property 'release_confirm' not found in keymap item 'MBALL_OT_duplicate_move'
Warning: property 'release_confirm' not found in keymap item 'GPENCIL_OT_duplicate_move'

Think this is nearly ready for inclusion, blockers AFAICS.

• Currently there are invalid properties in the keymap that show as warnings, these should be resolved.
• String properties are used for what should be enums for the operators.

Both of these are fairly straightforward to resolve.

Open Topics:

• Presets have no mechanism to unregister operators (once enabled, these operators will never unregister).
• Using the preferences for a summary of shortcuts seems strange/misuse of preferences.
• Replacing Cmd for all shortcuts might cause conflicts with the OS? Some macOS global shortcuts use Cmd

@Campbell Barton (campbellbarton)
Yes, am sorting out those issues. I have already converted the ops to enum properties.

> Presets have no mechanism to unregister operators (once enabled, these operators will never unregister).

Hmm yes, don't know how to solve/address that. Obviously in practice it is probably unlikely to cause issues, but it does seem ugly that enabling a keymap will add operators, even when you switch away from that keymap.
Only solution I can think of, other than accepting it, is to include these operators in Blender proper, so they aren't just part of the keymap.

> Using the preferences for a summary of shortcuts seems strange/misuse of preferences.

Yeah, I can remove it - it does seem a bit out of place. Although it could be nice to have the ability to have a little text box with the main shortcuts, or a little text explanation of what it's for. But then again, you can already see that in the menus.

> Replacing Cmd for all shortcuts might cause conflicts with the OS? Some macOS global shortcuts use Cmd

Yes, it's true. But luckily with your solution Ctrl continues to work :)
The main issues are Cmd-H and Cmd-M, which are used to hide and minimise the app, respectively.

Is there a way of resetting the 3D Cursor using the Industry Compatible Keymap? I tried to do this and couldn't find a way. The search bar didn't return anything, nor did Google, so I eventually just gave up and went back to default shortcuts. If this is going to be the experience of a Maya user using 2.8 for the first time, I can tell you that the vast majority of your users will give up, either on the keymap or on Blender itself.

I can understand the need to keep the keymap minimal, but perhaps there should be more pie menus enabled in this mode, so that the new user can find certain functions by clicking and finding it manually. Otherwise, the experience of the user will be:

1. Watch Blender tutorial
2. Realise that they can't complete (x) using the Industry Keymap
3. Look through a bunch of menus to see if they can do it some other way
4. When they can't find it in a menu, Google it
5. Google doesn't have any information, because nobody uses the Industry Keymap
6. Delete Blender 2.8 from hard disk, then Google "how to torrent Maya"

@Alan Noble (AlanNoble) Yes, use Right Click > Snap > Cursor to World Origin.

Please use this thread for further feedback: https://devtalk.blender.org/t/industry-compatible-keymap-questions-suggestions-and-answers/6911/21