Page MenuHome

User preferences for the default keymap (design task)
Open, NormalPublic

Description

Keymaps can now have their own preferences,

There is a limit to how many options we can reasonably maintain, so it may be we keep the number of options under ~5 or so.

Nevertheless, there may be some options worth adding, so opening this design task.

Current Status

Currently the default keymap has the following preferences which have been added based on feedback.

  • Select Mouse [Left | Right] (Was previously an input preference).
  • Spacebar Action: [Toolbar | Animation Playback] (Swap Space/Shift-Space)
  • Select-All Toggles (like 2.7x map)

Suggestions

Listing suggestions which seem like options we could support.

  • Swap Tab / Ctrl-Tab (Edit-Mode / Pie-Menu).
  • Swap 3D view MMB/Shift-MMB (Orbit / Pan).

Details

Type
Design

Event Timeline

Campbell Barton (campbellbarton) triaged this task as Normal priority.

There were some other options that crossed my mind, but I'm not sure of:

  • Option for spacebar to open operator-search popup

    (personally I wouldn't add this, but some users seemed to prefer this behavior).
  • Tab Opens Pie-Menu (Swap Tab/Ctrl-Tab)
  • Support Tab-drag, to open pie menu (tab click to switch modes)

    Was in 2.8x for a while but the click-delay wasn't an acceptable default.

Again, not convinced these *should* be added, just that we could if we think it's worthwhile.

Campbell Barton (campbellbarton) renamed this task from Default keymap preferences to Default Keymap Preferences (design task).Nov 18 2018, 4:21 AM

Hi Campbell. Love the initiative for giving users more options to easily access the switching of keymap functions which would otherwise be quite intimidating and time consuming to change within the Hotkey Editor itself. :)

So changing these settings, how will it work on the keymap exactly. Will it be 'Limited' to, Use This or The Other -or- Use Both Together, kind of setting? (Surely using both won't work with all hotkeys. But maybe for some?)

I'm asking cause I'm thinking about 'Dbl-Click' Loop Select vs. 'Alt Click' Loop Select. (/w + Shift = Add/Remove Toggle) But in this case, it doesn't necessarily have to be 'One or The Other'. Can easily be 'Both' like its currently setup. But having this option in preferences will;

  1. Make users aware that there's 2 ways of actually doing it.
  2. Allow users to select and use 'Only' the method they prefer. To avoid any accidental 'Click/Dbl-Click (De)Select' issues or confusions with Multiple Clicks/Modifiers Key setups doing the same thing.

Also how about a setting for, 'Show Quick Favorites in (Right-Click) Context Menu.' --- If implemented, Surely this will be a sub-menu otherwise it'll make the RMB menu way too long. But still, for Keyboard users who use 'Q', might not really want this in their RMB menu as they'd want the mesh related settings and/or other add-on stuff like Loop-Tools, Etc at the top of that list. But nevertheless, always good to have an option for users to select what they'd like to use rather than hard-lock it in. (Most software have this option for showing stuff in context menus. 7-Zip, for example.)

Hope all this makes sense. And thanks for all the hard work man. Appreciate it. :) Will add more ideas as they come up.

Hey Campbell,

I´m all in for Tab-drag to open the pie menu and space bar for search. I was kinda sad to see the feature go but having them now as an option would be perfect.

i tried the tab drag and tab click myself, changing pie menu threshold and everything, it didn't work well,it always has issues,
so i mapped it to tilda keeping tab for just edit mode........for spacebari think many will pick their own, animators want it for playback, others for search and people like me stick with Active tool..i think the default should be something simple and easy for new users who won't be frasutrated trying to figure out all these complex combinations and what not,the veteran ones know how to navigate and change these Behaviors , heck even i could ;)

@Zino Guerr (Zino): What @Campbell Barton (campbellbarton) here suggests is an option to essentially flip Tab and Ctrl-tab. This means that Tab would always spawn a pie menu, not tap vs drag, which indeed is too finicky.

@William Reynish (billreynish) ah i see, this means the edit mode becomes ctrl+tab that's a bit slow, i would suggest each should be it's own hotkey, like tab for edit mode, tilda for pie menu and alt+tilda for view modes, snapping is already shift+tab and since ctrl+tab is free it can be assigned to snapping menu, i even added ctrl tilda for view navigation..u guys can try this and see if it works or not, thanks.

@Zino Guerr (Zino): I don't follow. Blender has more than two modes, so opening a pie menu is a reasonable solution. If you really want to enter Edit Mode with this option enabled without opening the pie, there's Ctrl-Tab.

@Gibran Kaleel (razgriz286),

  • Not sure we're keeping double click for loop select? As mentioned in design task - this means 4x clicks for boundary select which isn't great.
  • Showing quick menu in context menu could be done but shouldn't be a keymap option.

@Zino Guerr (Zino)

  • pie menu on tilde could be OK option since the view menu is just a second way to access view options already accessible from the num-pad (no strong opinion here).
  • As for keeping ability for space-bar search. Would like to hear from users who want this but *not* users of 2.7x keymap.

@Campbell Barton (campbellbarton): The main reason for double-click for loop select as an alternative, is that it's a way to allow for loop selections when you are using Emulate 3 Button Mouse, which is needed for tablets and many laptops. We could also make it so it only uses double-click for loop if Emulate 3 Button Mouse is on?

@William Reynish (billreynish) as of right now tab switches edit/object modes and ctrl+tab opens pie menu and the suggestion is to flip them right!!..as far as i know people switch to edit mode more often than the others..i am fine with whatever you guys pick since i use tilda for opening the pie menu instead it goes well with shift+tab for snapping and ctrl+tab for snapping options.

@Campbell Barton (campbellbarton) Double click for loop select is very handy. And since it's an alternative, I don't see a reason to change it.
I hope it can stay as it is.

@Zino Guerr (Zino): Well, for some users that's true, for others not. Some people mainly use Blender for sculpting. Some people use it only for character animation, etc. Tab going to Edit Mode only makes sense for a certain subset of users. I don't like the fact that we have all these modes, but Tab switches to one of them only. At least this option makes is to that other types of users have an easier way to switch to the modes they are likely to use.

How would these options differ from editing the keys directly in the keymap?
Are they just quick toggles or easier ways to swap stuff around, without requiring digging into the keymap, or avoiding conflicts?

If so, I'd say that since we have a limited number they should be reserved for stuff that is hard to swap out manually, or require multiple changes across various contexts.

I do miss spacebar search, but it seems easy to change back. Maybe these could be reserved for more complex stuff stuff like altering behavior of selection modifiers keys across multiple selection modes. Say what does Shift, Alt, Ctrl do in Click-Select, Border Select, Paint-Select or Lasso, keeping behavior consistent (add to selection, remove, toggle).

Maybe also default middle mouse button action (if we are keeping them) like Rotate View vs Move View.

Campbell Barton (campbellbarton) renamed this task from Default Keymap Preferences (design task) to User preferences for the default keymap (design task).Nov 18 2018, 10:35 PM

@Duarte Farrajota Ramos (duarteframos) - for your first comment, yes - this is quick way to change keymap behavior without having to dig into editing the keymap yourself.

To begin with Id' rather not limit suggestions, if you think something is useful - propose it. Later we can sort through them.

The problem with adjusting how modifier keys behave is this may impact different keymaps, since keymaps overlay on top of each-other.


Swapping MMB action (rotate / move), is the kind of thing that's well suited to being a preference. Would be interested to know if others would find it useful.

In general - swapping keys used for related tasks is something we can support since they're unlikely to conflict.

@Campbell Barton (campbellbarton): What about the preferences for keymaps we already had in the past? I'm thinking of things like Emulate 3 Button Mouse and Emulate Numpad. These are essentially keymap preferences, right? Should they be ported to this new system do you think?

@William Reynish (billreynish) they are candidates, although both of these are handled in the event-system, currently which makes it easy to leave them as-is, without having the problems introduced by LMB select.

Emulate MMB will make the keymap very messy, so for practical purposes I'd leave this as-is. ~ Edit, this isn't true if we post-process the keymap - swapping out all MMB with LMB, adding alt).

@Campbell Barton (campbellbarton): Ah yes that makes sense. It's cleaner to handle them in the event system so the keymap doesn't have to worry about it. I only wonder if those options always make sense with other keymaps though. In any case it's not a big issue either way.

I see in that case a few controversial ones that come to mind.

Space Bar behavior and Tab key behavior seem worthwhile

  • Default Left Click tweak/drag behavior > [Move | Border Select] In case we can't get them to play nice simultaneously by detecting where the rag behavior was started from-
  • Default Left Click selection behavior (no modifier keys) > [Add to selection (sticky selections)| New selection (reset on every click)]

@Campbell Barton (campbellbarton) from the old proposal of "industry keymap aka compatible keymap" i saw that u guys going to make Alt+LMB for rotate Atl+MMB for panning and Alt+RMB for zoom, is that scraped?it could work ...for the spacebar at least for works well as it's,
the UI now is more clean and easy to discover all options epescially with tool/top-bars..etc, accessing tools in quick and easy way is more convenient and it's contextual,F3 makes perfect sense to me..but like you said more users need to give feedback on this.

Not sure how this is planned to be handled in the new keymaps, but one other possibility for keymap settings is the behavior for move/rotate/scale hotkeys.
Will old behavior for direct operator invoking (grab/rotate/scale) be kept in parallel with the new tools workflow?

Last I read you were planning to use W E R for Move Rotate Scale, maybe a keymap option could toggle between activating the corresponding tool, or invoking the old operator.
Some modifier key could be used to override default behavior.

@Duarte Farrajota Ramos (duarteframos) seems like your talking about bigger changes to the keymap.

Don't think these relate to keymap preferences.

Currently there are no plans to remove direct operator access. The industry-compatible keymap will likely work this way.

Currently there are no plans to remove direct operator access. The industry-compatible keymap will likely work this way.

Didn't mean to imply bigger changes to keymaps, I was under the wrong impression direct operator access might get replaced by active tools.
Good to know they'll be kept around then.