Another thing that I already wanted to ask if it’s ok for you to ask for additions to context menus here if they are “lacking” because of IC keymap restrictions. Or is that out of scope?
If something isn’t really possible because it’s missing in both the context menus and as shortcut keys, then I think it’s fine to mention it. It’s always useful.
Wow, is that new, didn’t saw that before? Anyway, thanks for the info.
So here’s a response for each item you brought up
I think you mean the ability to set the vertex radius? You can set it here in the Sidebar:
It might be possible to add as a shortcut also if you have a specific suggestion that doesn’t conflict.
Not sure what you mean exactly. You can find all the Mask operators here:
It’s also possible to improve the Mask tool:
Is this the bracket issue with German keyboards? Any concrete suggestions?
Yes, I generally didn’t alter modal keymaps since modal operators is mostly a Blender concept anyway. It would add a lot more changes, but if it makes sense it could be worth it. How exactly would you change them?
That is absolutely true, and one of the reasons I looked at adding keymap prefs to the IC keymap - to make it much easier to make common tweaks.
Yes somehow, I was talking of the Skin_Resize tool in particular as the direct interaction method needed for resizing the vertex size attribute. But thanks for the tip, missed these sliders indeed. I described it in more detail and with shortcut proposal here:
I am talking of “Expand Mask by Topology” and “Expand Mask by Curvature”. Both tools “selection drawing”-tools that start at the mouseposition. So having this in the menu is useless, well not completely useless as it’s a good way to identify the shortcuts for users. But these two don’t make sense without shortcuts.
I proposed Shift+A and Alt+Shift A for that. These only conflict with ViewFrame ( Goto Playhead). Thats why I proposed to unify that prior to assigning them to the Exand Mask tools. Read about it here:
The rest of the mask tools has shortcuts. Can you tell me why blender does not display them in the menu?
Could make sense for controlling for adapted versions of select more / less and sharp / smooth . But for the expand tools I was referring to that makes no sense for the same reason. You have to trigger them with the mouse in place on the model.
Not solely, but yes brackets are part of that. I will have to reply to this separately. Some month ago, I put some work into identifying the commonalities between the keyboard layouts we should respect., but I haven’t yet compared that to what of these areas are still free to assign.
I would align it with the differences between the blender and the IC Keymap itself. Many shortcuts refer to other blender shortcuts. These could now resemble the ICKeymap if that is active.Some for example the Transform tool itself, still use G R S shortcuts. I’d change these to W E R. We would have to go over them one by one. If you are ok with the idea to work on that, I could prepare proposals.
The bevel operator’s modal keymap is a bit too easy to pick on, but it could serve as a point to work backwards from. I’m generally a fan of frequency clusters over mnemonic patterns, and clustering on QWERT would fit the theme of the IC keymap.
2 Likes
Thanks - I will tweak some of the modal keymaps too, and address some of the other issues mentioned.
1 Like
Concerning better support for different keyboard layouts, I’ll post some notes here, nothing special. Could be helpful to define a set of valid keyboard shortcuts that work on a wide range of keyboard layouts. Certainly does not all the work needed to define a valid keyset, but it’s a start. Feel free to add thoughts or corrections.
Keyboard Types:
- Numblock Present / Absent
- US: QWERTY Layout
- Mostspread keyboard layouts in EUROPE are are QWERTY and QWERTZ.
- France and Belgium have AZERTY
- Beside that there are also non-latin letter keyboard layouts, but these can just be ignored as they have de facto no overlap with the Querty layout.
- For Quertz, most of the european subtypes concentrate on some special keys for language specific special letters or letter accents, these don’t qualify for usage as predefined hotkey, beside that there is generally a big similarity among these.
I will refer to the namings of this keyboard topology description
Topology of a Keyboard:
-
Character Keys
- Letters - a–z reachable without modifiers, special letters mentioned above should not be hotkeys.
- Numbers - Just the french layout need Shift to reach them, most common keyboard layouts have them directly accessible
-
Other Characters, Signs, etc. - these need a closer look, some like minus seem to be widely present without modifier keys, but thats not true eg for the different brackets.
Verified: , . -
Diverging: <> [] {} / \ = + #
-
Special Keys
Numblock - not present on notebooks, but despite that its layout is almost identical in all defined keyboard layouts
Modifier Keys - present in every keyboard layout.
Navigation Keys
Arrow Keys - present in every layout -
Special Key Block ( Page up/down, etc, Pos1, end)
- almost every layout has them present -
System and GUI keys - present in every keyboard layout ( OS specific differences but non conflicting substitutes available)
-
Enter and Editing keys - present in every keybord layout
-
F Keys- present in every keyboard layout.
-
Function/Fn key - is typically a hardware specific switch that makes the keyboard send different keycodes. It normally can’t be controlled or utilized directly
Conclusion and possible guidelines for this keymap:
- for letters and numbers, navigation keys, f keys, Enter and Editing- Keys, System and GUI keys its almost true to say, that they all can be reached in every layout and without modifier keys. Because of that they are best candidates for blender as predefined hotkeys.
- they should be first choice for usage and should be utilized extensively with and without additional modifier keys.
- all keys that are not available on all keyboard layout should be candidates to leave free for user defined hotkeys
- keys that are just reachable with Modifier keys don’t qualify
- OS specific shortcuts have to be taken into account to prevent conflicts
- whenever there are defacto standards these should be priorized ( things like Ctrl+S for Save )
Links:
Options for supporting more keyboard layouts:
Problematic keys currently used in the IC Keymap are: / \ [ ]
- We could change problematic shortcuts to new candidates that fit all keyboard layouts
- We could duplicate shortcuts using problematic functions and change the duplicate to shortcuts exclusively accessible in other layouts.
- We could change the impossible shortcuts to exclusively reachable keys in other keymaps but embed them in language specific keymap subtypes like “Average (QWERTZ)” or “Maya (QWERTY)”
Option 2 and 3 are just possible by ignoring some QWERTZ subtypes. Not sure about these.
Personally I’d stick with Option1. Generally I think it should not be too difficult to tweak this map to support QWERTY and QWERTZ layout and partially AZERTY by sticking to the first option.
When it’s about number usage, I’d vote for ignoring the AZERTY layout differences. Removing the number usage for the IC Keymap is simply not valid option but I think workarounds like Autohotkey scripts could solve this for AZERTY users.
Thanks for the heads up. Some things I may look into, other things I don’t think are the province of the keymap per se. To me it seems like it should be handled in a more generic lower level place, to re-map QWERT to AZERT, for example.
I know that on macOS, you can set it so the keyboard shortcuts use QWERTY but text input uses AZERTY, for example.
That might ease quite some difficulties here. Beside that it sounds harder to solve than it really is as I don’t think many keys are affected. I just had to get into what really is a problem for what keyboard layout and as I thought this might be helpful for you too I posted it here.
As I see it, that’s should be handled at a lower level. I don’t think it makes sense to counter keys moving around on other layouts manually for each language layout. We could have a generic keyboard input preference that forces keyboards to use QWERTY for shortcuts, for example.
I agree, that keyboard layout subset idea seemed to me also a bit of an overkill. What about fixing some shortcuts like square brackets to get it running with Qwertz in the meantime? Not sure how you think about that. I’d still change at least these.
Beside that it also would be helpful to hear some of your thoughts on how to get modal keymaps discussed. A simple step would be to embed WER in the first place. But I
also find @ThatAsherGuy attempt for more clustered modal keymaps quite appealing. What do you think?
The left toolbar’s tooltips are no longer displaying python info even if its turned on.
_QWERTY_UK.svg){kind=link}
Might be because of the cycling-tools shortcut-display changes.
1 Like
That is definitely unrelated to the keymaps. If it used to work, file a bug report.
Yep, in Maya when you animate you press these keys thousands of times daily and they are stuck in your muscle memory.
Alt+V - toggle play/stop animation
Shift+Alt+V - goes to the beginning of the frame range
Alt + comma and Alt + period - previews/next frame (this is everywhere timeline, graph editor, dope sheet, etc.)
just comma/period - previews/next keyframe
1 Like
Yes, the Maya version does all that already, plus more. Perhaps I’ll start by simply offering a Maya preference.
1 Like
First off thank you so much billrey, this keymapping is what got me into blender 100%. Without it I’ve always bounced off blender every time I’ve tried it. So thank you immensely for your effort!
I’m wondering if there is anything I can do to resolve or fix the unwrap window? It seems its worse due to the industry standard keymap, because now no keybindings work consistently, not the blender defaults which is seems to expect, or the industry standard ones either.
Can you be more precise - what exactly is the issue with UV-mapping?
well to start, pressing 1,2 or 3 does not swap between verts, edges, and faces as it does in the 3d viewer window. which feels like the expected workflow, something that is consistent between max and maya for example. even using W E and R for translate, rotate, and scale don’t actually work. The keybindings seem to be there but the functions don’t work except for translate and drag box. Left click drag to select multiple things doesn’t work either. Those are the main ones I’m running into, I’ve avoided unwrapping in here partly for that reason, so there may be other spots i’m missing from my lack of experience with this blender action.