In T55386#510416, @Sergey Barabanov (huggaida) wrote:

• in edit mode press LMB to cycles between v/e/f (for example alt+LMB- cycles backwards). Since people used to Click/doubleclick LMB you will see how it easy to learn clicking once to switch from ver to edge, doubleckick to v->f

In T55386#509928, @justin barrett (justinbarrett) wrote:

In T55386#509748, @DIGVIJAY (DJAY) wrote:

hey, nice work guys. keep it up.

just for the suggestion ;

1. if the Properties editor's tab will be on the right side instead of the left it will be good
   
   and
2. it will be much easier and faster if the clicking is removed means just by hovering the mouse or as zebus (ofuscado) said by mouse wheel to the Properties editor's tabs (Render, Modifier, physics etc) it will open the relative tabs settings.
   
   
   

I agree, for single workspaces this very logical to have the buttons on the right...
A concern for me is dual monitor and mouse over events...I tend to have mine on monitor 1 with it dressed to the right...if I move to my second monitor I may accidentally activate an unwanted property mode....
I still agree with them being on the right though.

Currently, having search on tilde and view menu on hold tilde makes very little sense. Search and viewport switching are extremely different actions. Having them on same key doesn't make much sense.

When I've designed Corona UI, I've found out that just a simple introduction of proper vertical and horizontal UI element alignment can greatly aid readability of multi column layouts. So it's not that multi column layouts are inherently messy and less readable, but that they require a good, grid like alignment to be readable :)

In T54943#508047, @Campbell Barton (campbellbarton) wrote:

In T54943#508025, @William Reynish (billreynish) wrote:

They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved.

What would be the logic for solving this?

For preferences it's obvious, for two windows each the same size on a different monitor - its not. maybe this should get its own design task.

In T54711#506861, @Okavango (Okavango) wrote:

@William Reynish (billreynish) , @Campbell Barton (campbellbarton)

Guys, you might wanna check this out. This might be the first functional App Template, and with a lot of nice UI concepts for 2.8 to take inspiration from:

https://blenderartists.org/t/blender-pro-improving-blenders-interface-and-usability/1113152

Hi, any news on this bug? It really makes it impossible to use Blender as generator of fluid simulations for use in other apps. This should be high priority, because all the work spent by someone to make Blender support VDB is negated by this unwise file naming. I mean if you are doing sims to be used in Blender, you can just use the default point cache. VDB makes sense mainly because of interoperability with other 3D packages, yet this interoperability is broken for exactly this reason :(

I think that one of the included material preset should be thin, translucent foliage for materials such as tree leaves and grass blades (almost no high poly tree models have leaf meshes with thickness, otherwise it would be ridiculously highpoly model).

In T54963#505360, @KiJeon (0o00o0oo) wrote:

@Ludvik Koutny (rawalanche) It looks like context-sensitive menu is being developed as a whole anyways for 2.8 according to T55162.

In T55162#505355, @Campbell Barton (campbellbarton) wrote:

Regarding using number keys to select submodes.

While it is elegant in some ways to press a key to enter the mode, then the same key again to select a sub-mode,
I think users muscle memory for each individual number key won't be all that accurate, meaning the user will have to be extra careful not to accidentally enter a different mode.
It also means you don't end up with muscle memory for quickly tapping the sub-mode key (since it moves about depending on your mode).

Suggest to use a single, more easily accessible key for sub-mode switching.

In T55162#504999, @William Reynish (billreynish) wrote:

We discussed the number keys and decided to simplify it, so that the number keys simply reflect the main mode selector. This way, the order can be the same and be mirrored both in the mode selector and in the number keys. Other modes also have submodes and we want to make this work in a consistent way.

In T55162#504971, @Manuel Grad (manitwo) wrote:

@Ludvik Koutny (rawalanche) sorry, it wasn't my intention to suggest you're dissmissing exotic keyboard layouts. I just wanted to say that the number of users that would have to change the new proposed default would probably be pretty high. And the thing with defaults is that probably 95% of the people tend to stick with it. So they won't have a button for Object Mode. How many countries are affected by this? How many keyboard layouts are commonly used all over the world that don't have that key on that position? I don't know the answer. Does the Blender Foundation have statistics where the users are coming from?

In T55151#504978, @Philipp Oeser (lichtwerk) wrote:

This is actually working as intended, so calling this "corrupted" is not really appropriate.
I agree though that flipping index and framenumber would probably have benefits in a pipeline involving other software.
This could certainly be done [would need to take care of reading both naming-conventions then...].

Dont think this is a bug [more of a TODO - if at all], but maybe @Brecht Van Lommel (brecht) or @Sybren A. Stüvel (sybren) have a comment?

@Manuel Grad (manitwo)
Well if you see EDIT section of my last post, you will see I am actually not dismissing exotic keyboard layouts, but instead proposing a solution that would make such keymap work even with the exotic layout. The way you formulate your reply sounds like I am dismissing exotic keyboard layouts, which I am not.

In T55162#504930, @Campbell Barton (campbellbarton) wrote:

Regarding number keys for modes.

• Pose-Mode, Grease Pencil Edting - are missing from the list.
• Not sure we should give vertex/edge/face their own number keys.
  
  It's limited to edit-mesh, would we do the same for other modes? (particle also has selection modes similar to mesh, would we support sub-modes for particle editing... also how would this be used in the UV window?).
• If you mix multiple modes at once (vertex/edge/face), will there be a way to enter edit-mode without loosing the mode you had set?
  
  Also...
• How to handle having more than 10 modes? (which seems likely since you're already mapped nearly all keys).
• How to these keys be set when using non mesh objects?
• Not sure Search needs to be Tab (a very prominent key), we could use an F-Key for example.

Looks really good. I know this is not the industry standard keymap, but I would still suggest to shuffle it around a little so that 1 2 and 3 keys do Vertex, Edge and Face edit modes respectively. There are quite a few Blender users that have set it up that way, and it's just much more common. I do understand the reasoning though, as having object mode at 4 feels a bit random.

In T54963#504594, @William Reynish (billreynish) wrote:

Context-sensitive menus for right-click is not out of scope - it's exactly the kind of thing we want to enable with this keymap.

In T54963#504272, @William Reynish (billreynish) wrote:

Ludvik: Yes. This discussion got mixed in confusing ways with general features for switching tools. In the default Blender keymap, the space bar is uses for switching tools. In this Industry Standard keymap, I don't expect it to work like that, and for most tools it's not necessary, because users can simply use the shortcuts directly to switch active tools.

For this Industry Standard keymap, we should properly define how the right-click menus should work, and how the space-bar feature should work. We should analyze what all the apps do here to determine the most standard approach. Help in this area is much appreciated.

In T54963#504116, @William Reynish (billreynish) wrote:

Julian: In Blender 2.8 you can already switch tools in a popup menu by pressing the space bar. If you prefer to work full screen with a hidden toolbar, you can use this method to switch tools. It works in any mode, with all the active tools.

I see that the proposal to have "Sky" map defaulting as background was indeed removed, as I suggested. I know resources for Code Quest are limited, but I would actually be very happy if Sky map was finally finished with proper Physical Sun light and easy to do linking between Physical Sun and Physical Sky, so that it could indeed become a default. There's already an Omni light present in the factory default Blender scene. That Omni could be replaced by Physical Sun once implemented, and background could default to Physical Sky linked to that sun. So every new user, who would just hit render straight away would get a nice simple day lighting in his scene out of the box :)

In T54661#503597, @William Reynish (billreynish) wrote:

Extrude manipulators are unfinished still. They are too big, and secondary axes are too prominent. We have plans to make improvements in this area.

As for the multi-tool manipulator, it’s an interesting idea, but most likely not something we’d like to pursue. The different tools have different options and work in different ways, so it’s not as straightforward as one might think to combine them.

Also, we want to avoid error prone behaviors, where users might hit the wrong handle. This kind of thing could be implemented as an addon, though.

In T54963#503609, @André Savik (klutz) wrote:

For the Search/Quick Find function, I suggest the F1 key. As per today, it's being used in a non-standard way (Open File) by Blender (as so many other shortcuts), but this suggestion might actually keep the door open for implementing a "real" help system.

Initially, by pressing F1 you'd open the dialog that's now bound to the space bar. Later on, however, one might want to implement a new choice in that box so that you can choose between executing the command and opening a help function.

Implementation: Press F1, type Flip Normals into the text box, <Enter>. Just as today the selected faces will ble flipped.

Possible future implementation: Press F1, type Flip Normals into the text box, <Enter>. The selected faces will ble flipped.
But now, the dialog also gives you a second option: Instead of pressing <Enter> you can press F1 (or another assigned key) again and open up the help context.

I know I am probably old fashioned, but I really like back faces being shaded black, because I can constantly see the normal orientation. When one of the new 3ds Max versions made double sided material drawing default, at it was no longer possible to switch it back, I found that it was not an advantage, but a drawback, as I had to spend time constantly toggling diagnostic shading mode to see orientation of the normals.

In T54336#502722, @Philipp Oeser (lichtwerk) wrote:

@Ludvik Koutny (rawalanche): could you report the other inconsistencies as well? (just post into this report, I'll take care of them -- and see if it makes sense generalize some code here)

I would strongly suggest to have just one global border and lasso selection implementation which is referenced by all the editors, rather than having unique implementation for each editor and trying to keep its codebase manually in sync. There are quite a few more inconsistencies of lasso and border selection keymap properties between the different editor. This bug report is just a small example of it.

sorry for commenting on already closed task. There's one thing that won't stop bugging me, and it's somewhat related to the new manipulators:

Also, the best way to reproduce it after the input type is changed to "Any" is to switch the focus away from Blender's Window to a different one and then switch back. Then it should happen almost every time.

In T55012#501359, @Philipp Oeser (lichtwerk) wrote:

Hm, yes, I imported that back in, but ANY doesnt seem to produce issues here?

• I can CTRL+G to group, CTRL+Tab to enter weightpaint, I can SHIFT+click to add to selection, etc...
  
  It would be the same as changing it from 'blank' to ANY in the default keymap as well, right? (so we wouldnt need the step of export/import keymap to reproduce...) Do you have issues, setting all these 'blank' entries in the Screen\Screen Editing section to ANY in the default keymap as well?
  
  I havent had a look at the code yet (I'm a little bit surprised myself), just saying: ANY doesnt seem to be an issue for these entries on my side...

In T55012#501350, @Philipp Oeser (lichtwerk) wrote:

Not sure I follow correctly:

• I changed the "Toggle Header" shortcut to Ctrl+F9 (instead of Alt+F9)
• exported keymap

When keymap is exported, these fall back to the incorrect "Press" action

Here I cant reproduce, my exported keymap file looks contains this:

kc = wm.keyconfigs.new(os.path.splitext(os.path.basename(__file__))[0])

# Map Screen Editing
km = kc.keymaps.new('Screen Editing', space_type='EMPTY', region_type='WINDOW', modal=False)

kmi = km.keymap_items.new('screen.actionzone', 'LEFTMOUSE', 'PRESS')
kmi_props_setattr(kmi.properties, 'modifier', 0)
kmi = km.keymap_items.new('screen.actionzone', 'LEFTMOUSE', 'PRESS', shift=True)
kmi_props_setattr(kmi.properties, 'modifier', 1)
kmi = km.keymap_items.new('screen.actionzone', 'LEFTMOUSE', 'PRESS', ctrl=True)
kmi_props_setattr(kmi.properties, 'modifier', 2)
kmi = km.keymap_items.new('screen.area_split', 'NONE', 'ANY')
kmi = km.keymap_items.new('screen.area_join', 'NONE', 'ANY')
kmi = km.keymap_items.new('screen.area_dupli', 'NONE', 'ANY', shift=True)
kmi = km.keymap_items.new('screen.area_swap', 'NONE', 'ANY', ctrl=True)
kmi = km.keymap_items.new('screen.region_scale', 'NONE', 'ANY')
kmi = km.keymap_items.new('screen.screen_full_area', 'NONE', 'ANY')
kmi_props_setattr(kmi.properties, 'use_hide_panels', True)
kmi = km.keymap_items.new('screen.area_move', 'LEFTMOUSE', 'PRESS')
kmi = km.keymap_items.new('screen.area_options', 'RIGHTMOUSE', 'PRESS')
kmi = km.keymap_items.new('screen.header', 'F9', 'PRESS', ctrl=True)

They fall back to ANY here (not PRESS) [which doesnt seem to produce issues -- but havent looked further]

Could you share your exported keymap?
Did I misunderstand something?

Marking as incomplete for the time being...

In T54963#501261, @William Reynish (billreynish) wrote:

We want to find a way to enable pie menus by default in Blender 2.8, both in the default keymap and in the industry standard keymap.

The main reason why it hasnt been on by default, is that is disrupts old habits, because you can no longer just hit, say, Tab to go to Edit Mode, because it now spawns a pie menu with all the modes. While that is mostly superior, because it allows you to quickly jump to any mode, we want to make it so that we can detect the difference between a tap and a hold+drag. This way the tab key can work as it did, but holding it will spawn a pie menu instead. This will require some testing and fine tuning to make sure both are equally fast, otherwise it defeats the purpose.

In T54963#501165, @Luciano Muñoz Sessarego (looch) wrote:

Maybe im off the line here,

But I'd try to keep these multiple hotkeys for similar actions under a pie menu (wasnt that the idea of implementing them after all), like one hotkey with the pie menu for cameras (like Q in 2.79), one hotkey with a pie menu for mode (like tab in 2.79), or like pivot point with "." or manipulators with "ctrl+space"

I thought the idea was to keep the standard default keymap to a minimum so you dont need to learn 10 keymaps only to change modes, just one that quickly gets you there.

thanks

In T54943#501167, @Luciano Muñoz Sessarego (looch) wrote:

Why render display "new window", I thought one of the base ideas of blender was no obstructing overlapping windows... ?
I totally agree with the rest of your defaults, I've set them like this myself for years in 2.79

Since people prefer to have mesh element keys not offset by object mode, so that 1 is always vertex, 2 always edge and 3 always face, perhaps ~ (tilde) key could toggle object mode.

One question: Why have you decided to default background to Sky when Sky in Cycles has remained unfinished in years?

Being a 3ds Max user for almost 10 years, I can with confidence say that 3ds Max unit system is one of the worst way to go about it. It creates more problems than good. I find the best scale systems to be the ones that define precision of the scenes based on viewport/camera near and far clipping planes :)

Here is another, practical example why turning off reflective and refractive caustics won't save us from noise:
https://forums.unrealengine.com/development-discussion/rendering/1460002-luoshuang-s-gpulightmass?p=1465988#post1465988

Cycles reflective and Refractive caustics should definitely not be off by default. This goes against the usability, as renderer should deliver visually pleasing output by default. You won't achieve that by making sure glass shadows turn out completely black and metallic materials won't bounce a bit of light.

In T54963#500085, @Timur Ariman (myclay) wrote:

I find the proposed alternative Keymap intriguing and clever for the most part but since majority of those which do Sculpting and Texturing tend to use Tablets, It would be nice if that big chunk of users could be taken into consideration too for the Viewport Navigation.

3D View:
Object mode:
Viewport navigation:

ZBrush has this as its primary keymap;

• Panning: Alt+Click & drag Background
• Orbit: Click & drag Background
• Zoom: Alt+Click, Release Alt, drag Background
• Center on selection: F
  
  While I agree for the most part with the proposed Keymap, it would be quickly fatiguing and imo counter intuitive for tablet users to have to use alt+MMB and Ctrl+MMB, mouse wheel with a tablet pen.

In T54963#500039, @Okavango (Okavango) wrote:

@Ludvik Koutny (rawalanche) How about doubleclik for entering / exiting edit mode? I have it in my keymap, it is fast and intuitive as an eyeblink and it could free spacebar for something else important...

In T54963#500035, @Bram Eulaers (Leukbaars) wrote:

Oh I think the reasoning is sound, and it's a good control scheme! But it's not exactly industry standard, which would be the goal of this keymap :)

Actually here's some more reasoning:

In T54963#500030, @Bram Eulaers (Leukbaars) wrote:

This is really awesome, I have gone to great lengths to set up my current blender install to similar shortcuts already. This should make blender very appealing to new users.

I would really reconsider the Maya viewport controls though, many consider them industry standard by now. It's used in quite a few game engines and editors. You mentioned unreal, but unity, source2 and substance painter/designer use it as well, and many others. In fact it's available as an option in 3dsmax after popular demand and pretty much every industry professional using max I've talked to uses the maya standard.
I really think industry standard camera controls should probably take priority over other shortcuts, it's the primary interaction you do in Blender.

In T54963#500024, @YAFU (YAFU) wrote:

I completely agree with Alberto.
But, does this pretend to be behavior by default? If so, I'm a little confused right now. I understood that there would be changes to improve consistency between all the modes/editors within the same Blender, and make things easier for new users who use Blender as the first 3D program ever, not to satisfy users coming from other programs. I entered/know the 3D world with Blender as firts program. Then I have tried other programs and I think Blender has the best mode for viewport navigation with mouse button wheel (and the pen on a graphic tablet). Only noticed the problem of the LMB select that we all know.

Anyway, please do not touch shortcuts that are really intuitive because they are related to the English name that have tools/elements in Blender.

In T54963#500020, @Duarte Farrajota Ramos (duarteframos) wrote:

If I may add I'd like to suggest a consistent use of modifier keys.
Currently in Blender the Alt key has become sort of a "reverse" or "opposite" operator for many keys like H hies Alt+H unhides, P Parents, Alt+P unparents, R Rotates, Alt+R clears rotation, you get the idea...

I really like this system; it is consistent and easy to remember, and I think it should be maintained and even expanded to other areas.
Selection modifiers for example if left click selects I think Alt+LMB should remove from selection, if border selection as a certain key, then Alt plus that key should remove too. Same applies to whichever keys are mapped to say circle select, and any other operators.

No more middle mouse button for deselection, potentially releasing this key for viewport navigation at all times, which is probably out of scope here but would really really love to see possible: Viewport navigation during operators or at least tools

@Alberto Velázquez (dcvertice)
Actually, this was adopted from Softimage XSI/Autodesk Softimage. It's a dead software now, but it had some very good concepts, with spacebar for object mode being one of them. It's written in the reasoning paragraph. Check the attached video example. You will see that edit mode exit/toggle action is frequent and useful enough to deserve key such as spacebar. Sure, search could be on spacebar, but as I already mentioned, when there is a quick search in CG software, it more often tends to be on Tab key.

In T54963#500012, @Alberto Velázquez (dcvertice) wrote:

One of the best things I saw in blender when I started using blender six-seven years ago was the search bar. You find her almost by chance, just by pressing space. In two seconds you understand its purpose. Thanks to it I had direct access to absolutely all the functions of blender at the time, completely unaware of the program, only needing to know what I wanted to look for. I learned half the program thanks to this. Is it good to remove it from its current location on a keymap for new users? it's hard for me to see it.

It is almost a wizard for fools, which unleashes the power of blender to any user.

I think Vyacheslav meant if it's going to be default. And it is explained near the top in the "Approach" paragraph that it won't :)

I agree with @Mantas Kuginis (MantasKuginis) 's suggestions. Many of other pieces of software solve this issue by having an UI element specifically for dragging the timeline. In Video editor it's usually a small arrow on the top or the bottom of active frame cursor. It would be nice to simply be able to left click and drag the green frame number indicator. It's a bit slower than right click, since you first need to move your cursor at that exact spot and then drag it, but it's what users are generally used to.

In T54661#498925, @William Reynish (billreynish) wrote:

For sure, we would want to make it easy to switch on startup.

Looking at your keymap might be helpful, although Blender 2.8 allows for us to actually emulate the industry standard interaction method much better than before, so we might want to solve things somewhat differently than you did for the 2.7 version, in which you had to work within the old limitations.

In fact, we may need help to actually create this 'industry standard' keymap. As you know, it's a fairly big job in itself.

The goal would be to make it truly like industry standard apps, where the W key activates the Move tool and lets you drag to move. Q for the select tool, and so on. RMB for context menus.

If you agree with this goal, and seeing as you experience doing this, would you be be interested in working with us to make it?

If so, we would create a Design Task here on developer.blender.org, where we can keep track of the Industry Standard keymap design. You could then start by implementing basic things like viewport controls, and QWER. Only add things that truly work. We could then keep a list of issues that might be needed to be changed in Blender to make sure the Industry Standard keymap works properly.

By then end, we could ship Blender 2.8 with the two keymaps. What do you say? Blender 2.8 might still be too rough to really make the final keymap, but we could start with a few basic things to get the ball rolling.

In T54661#498907, @William Reynish (billreynish) wrote:

That's cool. A few more thoughts, after discussing with Campbell Barton:

• Blender 2.8 actually allows us to follow industry standard conventions even more, if we chose to, because of Active Tools, which can be activated via hotkeys. This was not possible in Blender 2.79 and earlier.
• This means we can truly make QWER keys work properly in a way that's compatible with the industry standard, which we couldn't do before.
• In 2.79 and earlier, left click to select never worked well with the Blender keymap. Several tools were impossible to use in this configuration. We should not offer an option that doesn't work well, and leads to user error. We also have to consider why people use LMB select in the first place (because they want it to behave in a standard way)
• Many of the old alternative keymaps were not well maintained, and few people use them. There were too many.

What probably we want to do is this:

1. Keep Blender's keymap the default, and mostly as-is, with a few minor tweaks here and there to improve internal consistency. We would like to drop LMB-select completely here, because it doesn't work well, and doesn't follow standards, and makes working with tools awkward.
2. Add a second 'Industry Standard' keymap that works truly like industry standard apps. That means things like LMB to select, QWER for Select, Move, Rotate, Scale. F to focus. A to view all. T to show/hide manipulator. That kind of thing. This keymap we will make sure is well maintained, and works properly for all tools and modes.
   
   This approach will greatly simplify things, and will make it so we can make things really, truly work well with LMB to select. It means there's two options: the Blender way and the industry standard way, and that's it. It's simple. Old Blender users can use the Blender keymap, and people who use Blender next to other 3D apps can use the Industry Standard keymap. This way we think we can maintain it well, and keep the most users happy.

In T54661#498904, @William Reynish (billreynish) wrote:

The other thing is, for paint/sculpt etc, your solution would mean that you paint with RMB, which I don't think is a great idea, esp for tablets, which would become very awkward, and probably not a good default setup.

In general terms, I think we should do two things:

1: Have a way to preserve RMB select, but make it more consistent, so that RMB-drag is box select. LMB is used to perform the action and use manipulators. Otherwise it works more or less like today.

This would be useful for people used to Blender's current interaction model.

2: Have a different way to use Blender in a way that follows more standard conventions. That could mean many things, such as:

• LMB to Select
• RMB for context menus
• A quick way to switch between select and action tools
• W E & R for Move, Rotate and Scale
• Q key for selection
• etc.
  
  This would be very useful for people who switch between many apps, and maybe don't already use Blender, but would like to integrate it into their workflow.

In T54661#498903, @William Reynish (billreynish) wrote:

Ludvik: It could work that way, yes. But then that means that interacting with manipulator widgets etc is also done with RMB to avoid clashing with selection. If the main rationale for making LMB select the default is to make Blender more 'standard', then that solution would be equally as non-standard, just in a different way, and I can't really see the advantage.

Some of the solutions that involve LMB to select could simply follow more standard 3D app conventions. It's not like people aren't able to get work done in other 3D software, even if they have to switch between selection and action. People make entire feature films working this way, and it's fine.

In T54661#498888, @William Reynish (billreynish) wrote:

Luciano: Yes, I thought of that too. The right-click-drag to move feature is now pretty redundant. We might as well just allow users to right-click and drag to do box select.

Ludvik: We have not yet decided to set Blender to use LMB by default. Personally, I'm sympathetic to that idea, and it could have some other advantages, like opening up RMB for other, more useful things. The downside is that users then have to switch between action and selection.

In T54661#498888, @William Reynish (billreynish) wrote:

Luciano: Yes, I thought of that too. The right-click-drag to move feature is now pretty redundant. We might as well just allow users to right-click and drag to do box select.

Ludvik: We have not yet decided to set Blender to use LMB by default. Personally, I'm sympathetic to that idea, and it could have some other advantages, like opening up RMB for other, more useful things. The downside is that users then have to switch between action and selection.

In T54661#498851, @Luciano Muñoz Sessarego (looch) wrote:

Given that RMB selects, i wouldnt mind having RMB drag select in box mode, and with Ctrl Modifier be turned to lasso.
I think that would be totally great TBH.

It also seems to me that "lasso, circle, and box" select shouldnt be considered tools but secondary ways to the RMB selection.
Also I would encourage the change from circle selec to paint select because circle feels like you'll get a circle selection like in photoshop, because box select does that, draws a box.

Love you guys, keep it up!.

In T54661#498830, @William Reynish (billreynish) wrote:

Ludvik Koutny:

Your question has several answers. First, all of those things ultimately depend on the keymap. If you are building your own, it's hard to answer your question, because it then depends on how you set it up.

By default, the left mouse button executes the active tool. If you have the Move tool enabled, dragging with LMB moves the selected item. If you were to switch to LMB select, you'd need some way to switch. One way to solve it, is to simply switch to the select tool. This could be executed using a hotkey to make it faster than always clicking the tool in the toolbar. Another way would be by holding some kind of modifier key, so that if the user is not using the select tool, he/she can still select things by holding, say, the Ctrl key.

In T54661#497970, @William Reynish (billreynish) wrote:

Ludvik Koutny: The plan is to make it so you don't have to disable a tool, even if you make a new selection. That way, you can keep the Move tool active, and just switch selections and move. There would be no extra steps as you suggest.

And yes, the circle around scale is one we've actually considered for precisely the reason you outline.

The current state is pretty nice. Thanks for taking all the feedback into consideration. Congratulations on getting this done :)

In T54662#498292, @David (activemotionpictures) wrote:

Could the current representing numbers in a square icon when doing a long pre-calculation in render be switched to a spinning blender logo? Like it's "blending"? Spinning is always a good choice for waiti g processes.... like building light caches.... :)

In T54662#498137, @William Reynish (billreynish) wrote:

Ludvik: For sure, we could go down this route. One of the advantages of the current ones, however, is that they are maybe a bit more specific, relating to their respective manipulators. We definitely could use more generic icons here, but Blender already uses arrows and boxes in many places, so we want to make these stand out as something more tool-like. We may try some more variations and do some tests to see if other approaches work well.

I think the part of the issue as to why transform gizmo icons look out of place is their design. They use combination of the some colors (green), which are used as color codes to differ operation types on the icons below.

I've made a very thorough complete overhaul of Blender's default keymap. I've spent over 80 hours on it. It's quite intuitive in many areas, so I guess it could help as a reference not only here, but also in following input mapping changes.

I am curious, are those icons rasterized on the fly or only once and then cached? I mean, rasterizing every icon as 3D object in real time would consume a lot of resources, wouldn't it?

In T54661#497683, @William Reynish (billreynish) wrote:

Yes, we probably should fix this issue regardless, yes.. The little ring it also very hard to select. You have to hit the ring exactly, it doesn't register if you drag from anywhere inside it.

In T54662#497679, @Robert (robertshatty) wrote:

Color change on mouse hover (From desaturate to color) is bad practice. instead of changing icon color on mouse hover or pressed, just change background color.

Well, my original point was that I don't see anything wrong with this set of icons, shape wise. Maybe only bisect and knife could be distinguished a bit more (Bisect one could have semi transparent plane cutting through the cube). But I see no point in solving color blindness for icons that are already unique when it comes to shapes and look professionally designed.

In T54662#497506, @Hubert Tomaszewski (rndmnm) wrote:

@Ludvik Koutny (rawalanche) About 8% of males are affected by colour blindness. That is not insignificant. Also, IMO, the "bisect" and "knife" icons are unnecessarily similar. There is a clear difference in the way they work, and it just isn't represented in the design. Maybe design similar to the "comb" icon could be used, with the tool symbol?

Every single icon presented here has an unique shape. Even if I make them monochromatic, I can still easily distinguish every single of them. I think there's no reason to overthink it. If you had to accommodate UI design to everyone's disability and preferences, then it would be impossible.

I have one idea which could make keymap management for object transformation a bit more straightforward.

In T54482#497481, @Philipp Oeser (lichtwerk) wrote:

@Ludvik Koutny (rawalanche) : have a look in T54582, this only comes into play, when you have the scale tool active

In T54661#497386, @William Reynish (billreynish) wrote:

Philipp: As it stands now in 2.8, this issue is already fixed. Drag from anywhere to scale uniform, so you don\t have to use the circle.

In T54482#497399, @Philipp Oeser (lichtwerk) wrote:

Just found out that in 2.8 this issue is already adressed (you can click anywhere, not just the circle), see comment in T54661 also.
So I guess this can be closed as "wont fix in 2.79, done in 2.8"

By the way, not sure if this is helpful (if not the sorry for cluttering this task), but I am attaching two themes I've made. I find them surprisingly close to your proposal.

it looks mostly nice. Here's some of my subjective feedback:

Well, the current state is so sensitive that you are literally not able to scale a cube to a desired size (especially when scaling down), because you are limited to a pixel density of your screen. It is so sensitive that moving a mouse cursor just one pixel on a 1920x1200 screen will scale the cube by a quite significant increment. I think that not being able to effectively scale a scene objects using a 3D manipulator fits into a definition of a bug.

In T53904#481641, @Campbell Barton (campbellbarton) wrote:

An issue with switching back to ortho on snapping is it will only happen at some orientations.

If turntable is used this is mainly an issue for top/bottom views - where you may snap to the top but look down from a different rotation.

The result would be snapping to the top would only switch to ortho if it matches pressing Numpad7.

We could switch to ortho but keep the view named "User Ortho".