I would be happier if they listen users, like other devs do, and they implement ideas with iterations in the design, not in the code.
Implement two or three times the same until it works is one of reasons, probably the least important, because code quest will end in april when the official planning was October.
Re. Using the hotkeys to switch tools:
The main idea here is that we will do this by default in the Industry Compatible keymap. Most other DCC apps work this way, and it can become quite fast when the common hotkeys are bound to switching the tools. Most large, big budget pro animation feature films were produced with tools working like this, so itās not prohibitive to being productive or creating top quality results.
One of the main things that make them slower currently is the fact that switching between them is slower.
In any case, the alternate keymap will work this way, and there could be an option for the default keymap to work this way too.
I think that explains many of the usability changes in blender2.8 and the lack of affection for T-shelf and the workflow in blender2.79.
Yes, weāve all worked in companies that use that software, and weāve all seen our colleagues work perfectly at half the speed. And no, itās not a joke, in my last project I had to see a colleague even accusing me of subcontracting people because he couldnāt believe the speed with which I worked.
Billā¦
I used Max Xsi Maya and Lightwave ā¦ because to work in productions I had to use these for strength ā¦
so I know their āstandardizationsā well ā¦
yet I always preferred blender when I had to model and get results as fast as possible ā¦ because objectively it was always better and faster ā¦ compared to other applications ā¦
ok you want to standardize everything to get the widest possible users ā¦ I understand ā¦ but please ā¦ do not destroy the speedworkflow ā¦
as the veterans are accepting the compromise, even the newbie must harness their compromises.
it is not blender veteransā fault if the standard industry is going to ā ā ā ā off with these stupid ālicense at timesā that vampire their users or put entire communities into failure overnight making some applications obsolete for purely strategic and economic reasonsā¦
the nice thing is that many of these users ā¦ for years they made fun of it that blender was a toy ā¦
and all because they were pumped by the promotions of their wonderful beautiful programs ā¦ and they were lazy as a ā ā ā ā to try to deepen something that in their eyes seemed āfree = not good, or toyā
ironically now some of they continue with the teasing and want to brainwash an entire culture of workflow ā¦
and just to make things clear ā¦
the true standard ā¦ itās blender ā¦ not āthe standard industryā ā¦
whole generations know first blender ā¦ and then āthe industryā ā¦
true story ā¦ I had similar situations ā¦
@nokipaike I think you misunderstood. Please donāt misquote me. I didnāt say we should do this in the default keymap. We deliberately chose to make the default the way it is: use shortcuts for blocking, immediate transforms, and the more visual toolbar for a more visual workflow with active tools and gizmos.
What I did say, is:
1, itās a fallacy to say you canāt be productive with using tools, as many many films and productions have shown
2, it would be faster to use them if the hotkeys were bound to the tools.
3, the whole concept of the standards-oriented keymap came from the idea to create a way to use Blender that is useful for users who use Blender in heterogeneous environments, as part of a larger workflow. Maybe those users jump back and forth with Unity or Unreal, or they use Substance or Maya for other parts of the pipeline. In these types of scenarios, a more standardized approach to tools is appropriate.
Just be aware that thereās a certain inherent circular logic fallacy in saying āwe should not add shortcuts to X, it is too slow to activateā. Clearly, X would be faster to activate then.
Letās just have one, good keymap 
I mean, a few months ago, it looked like that switch from right to left click will start World War 3, or that at very least, the userbase will be divided for years to come. The change has been done now for just a couple of months, and I can already see such a large proportion of Blender userbase stopped to care about right click select, that it may not even need to be maintained in future, because right click userbase will likely dwindle down to nothing within a few months.
I think if we get a single, good, modern keymap, same thing will happen. Letās just make the current one optional, letās make a new, proper one, based on common sense, and I can guarantee you that within a year, the current one will end up so forgotten no one will care about it being kept up to date.
Overall I am sympathetic to this point of view. Itās generally the right approach - quality over quantity.
But completely eschewing Blenderās previous keymap and concept is a really drastic change - we even did experiments with removing the tab key for a more logical use of the number row to invoke any mode, which a lot of Blender users found too hard to swallow. And that was just a single key!
So, for now, we decided to go with this strategy:
An alternative strategy would be something more like a merging of the two keymaps, moving to QWER for the basic transform tools, and then having a preference to choose if they should invoke immediate/modal tools or active tools. This way there really is only a need for one keymap, but still with two ways to use the tools.
This would still require Blender users to completely throw out any muscle memory, but has some nice advantages too. Even if you like the immediate/modal tools, the WER keys are more ergonomically placed on the keyboard compared to GRS.
Yes, I agree. But the issue I have with the approach is that both Blenderās current keymap as well as the proposed Industry Standard Keymap are lacking in terms of ergonomics, especially with modeling tools. There is a certain basic set of modeling tools, or tools in general, which should be easily accessible all the time, such as extrude, inset, loopcut and bevel.
In both current Blenderās keymap as well as the proposed Industry standard one, for example shortcut for Inset is set to I key, which is quite inconvenient to reach, and at the same time, thereās quite a few unoccupied keys much easier to reach.
This was a practical example of a broader issue, which is that both āindustry standardā hybrid keymap, and Blender 2.7 style keymap are keymaps which fail at ergonomics. Yet there is no third keymap planned. None of these two planned keymaps address the issue of hand gymnastics currently required in Blender to do even the most basic of things 
EDIT:
Iāve made a graphical example of how I think the keymap creation should be approached, in all modes and editors. Basically, the more frequently the feature is used, the easier it should be to reach
Maybe this would be a good use case for Campbellās new and improved keymap options, a quick toggle between QWER invoking the old direct use operators or the new active tools
Users have always bet on a unique keymap with options, we have even openly defended the use of WER (we only lost E key actually). Because as many of us have already said, if the Maya/max keymap has not worked, a keymap that is a remix of max, maya, cinema and houdini will not work better.
Thatās not true, the problem was not moving between editing modes using numbers, the problem is that it eliminated showing or hiding collections (that use numbers) which is something that is used thousands of times a day, to exchange editing modes, which is used very few times every day and 99% of the time is to move between object mode and edit/pose mode. And for a secondary function 10 main keys of the keyboard that made a primary function are lost.
The solution that has been discussed several times
Tab - Edit Mode/last mode
Tab+drag - Show list of modes.
It is much more useful, functional and easy to understand.
We tried this but it was too error-prone. If you use tab while moving the mouse, youāll get different results that if you stay still.
But it was tested internally or openly with beta?
In the moment that users know that hotkey and hotkey+drag are different things he will know to avoid problem. Same happens in other softwares. Obviusly old users will need more time to learn new way, but I use it after 10 years of using blender and I only needed one hour to use it without problems.
Prone to error is the facedots off by default, where is hard to know what are you editing. Or the new pie menus, that are really hard to read and you canāt change by old menus with a option.
7 posts were merged into an existing topic: Blender UI paper cuts
What I would love is a preference to globally turn off all the modal tools and use only their active tools equivalents.
As has been mentioned already, there is a way to use the keyboard to switch tools.
Use the key-map preference for space-bar to switch tools.
Then you can use the Spacebar as a tool modifier: Space-G for grab, Space-R for rotate, Space-K for knifeā¦ etc. Pressing space isnāt any harder then Shift or Control, so this can be done fairly quickly.
Interested in feedback, do people who like to switch tools via key bindings find this handy?
I think its weak we donāt support convenient key-bindings to switch tools by default, but artists in the studio preferred using space for animation, so we went with that.
This was in our daily builds for a while (perhaps a week or so?), we had some bug reports from users wondering why switching to editmode had become slow - we all agreed it added a delay which wasnāt nice as a default.
Once you know to expect this itās OK (even handy), but all things considered I wouldnāt push for it by default.
as far as i tested blender is fast only in using hotkeys the rest parts like switching between modes,toolsā¦etc is completely different from other programs and itās slowā¦so all those claiming itās faster are wrong,trying to remember hundreds of hotkeys along using other apps is not fun, thatās why i think going with pie-menus for modes was a great choiceā¦and people shouldnāt forget that most devices used today are not just keyboard and mouse but a bigger range.
@ideasman42 Currently thereās no way to add ānumber of cutsā interactively with the scroll wheel when using the loop cut active tool, like how it works when we hit ctrl + r.
So it would be possible to add a shortcut like Ctrl + scroll wheel for that? It would be really handy.
I think that itās because in the studio you have more animators than modelers.
But in general I think that new keymap and toolbar need a polish work. Especially the select and transforms tools need to use pasive tools concept.
The toolbar is hard to understand, you are changing all the blender menus to pie-menus, without easy option to revert this, but then the new toolbar is a classic menu with 15 elements.
