@Sebastian M Roy (sebastianmroy)
lol, ok that blender is not industry standard ... however, you too son, could investigate 10 minutes more before trashing it for 10 years

Removed blank gizmo rB678c2003097d4a5f2def4e8a6f014420ad609d6e, closing.

Hi, I did a survey to more than 30 people in a game development studio. Thanks @William Reynish (billreynish) you are the only person in Blender who understands UX, thanks for working in a more standard interaction. The first time I tested Blender was when they launched Sintel, downloaded and tested Blender, I thought it did not work on my PC, I thought blender did not work well in Windows, it was a program only for linux, because "I clicked and did not do anything , LOL". And I never tried it again, it took eight years.

Maybe self-collision setting of cloth simulation ON by default?

@Jacques Lucke (JacquesLucke): I think your gizmo here could be useful, if it's reliable enough with multiple points selected. The main thing was just adding this tool in the first place - you gone above and beyond and made a nice looking gizmo too.

@William Reynish (billreynish):
I see, makes sense. Just have to figure out how to link the gizmo more to the tool, so that it is not visible when the tool is not active. I'll have to wait until the py api for that is ready :)
I also don't care too much if we don't use my code in the end, it was more an exercise to better understand how to create gizmos in Python at all.

Well, not all active tools necessarily have to have a gizmo if it doesn't make sense. For example, all the drawing tools obviously don't have any. Also, for any tool that simply affects a single value rather than a transform along several axes, we also don't display a gizmo for those. See Extrude Along Normals, Bevel, Inset or Smooth for examples. For those, the user just drags in the viewport to change the value.

Is this task not done? Can I progress it?

@Duarte Farrajota Ramos (duarteframos):
hmm having an axis show in the direction of the current tilt is a bit harder. Not sure if this can be done in pure Python. Depends in the selected twist method I guess...
Snapping is probably even harder but we'll see :)

In T54963#541129, @Rick Yorgason (Skrapion) wrote:

I see a bunch of these have been marked as "DONE". Where is the work on the current keymap being done? Is there a keyconfig or a git branch I can try somewhere?

@Adam Preisler (Alphisto): Colors will now be handled by the theme, not the icon glyph. This has many advantages - it makes them readable on both bright and dark themes, and it makes it possible to customize their colors to be strong or subtle.

In T53840#505679, @Andrzej Ambroz (jendrzych) wrote:

1. in real use, icons are apposed in UI in small bunches that are contextual. Colour ain’t that much needed here. Honestly, some of current icons pop out too much because of their colour, attracting user’s attention to particular parts of interface. It would be good to incorporate some colour codes though - in File Browser, Asset Manager or Outliner. In every place, where one has to manage big lists of items.

@Jacques Lucke (JacquesLucke): That looks pretty awesome!

That looks pretty good already, very useful, many thanks.
Only suggestion I can think of is perhaps to draw some sort of local Z axis pointing to the current tilt direction, to make it clearer to the user where it is currently facing.
If possible even two axis one for X and Y. Bonus points if these axis are actually capable of snapping to other geometry, for precise tilting.

Hey, I tried to implement this tool to get more familiar with the tool system here: https://developer.blender.org/D3804
It does not really work as intended yet but I have questions.

I'll spam this here too: https://devtalk.blender.org/t/angular-snap-needs-to-be-decoupled-from-incremental-snap/2161

@Brecht Van Lommel (brecht) @Campbell Barton (campbellbarton) Are there any plans on fixing this bug any time soon?
I heard at some point that there is more work being put into how the tools for the brushes work and maybe also on how you cycle between them? Is that why this task is on a lesser priority?

Bill: Thanks for positive feedback. If possible I would gladly put more of my time and knowledge into this... (testing, feedbacking...)
Which of the things I mentioned above, you think would be possible to consider for industry standard keymap?

This is shaping up to be an excellent revamp of the default key map.

@Duarte Farrajota Ramos (duarteframos) You mean "This is shaping up to be an excellent industry standard key map", right? The default Blender standard key map is another task altogether.

This is shaping up to be an excellent revamp of the default key map.
My only concern so far is that I think Select All operator should be mapped to Ctrl + A, in the name of keeping up with "industry standards".
It is the common select all in many applications, and the default behavior in operating systems, like the file manager, lists of items, or text input boxes, among others.

I think evaluating the scale and transform handles before rotation and putting them outside the "rotation sphere" would be the best solution - even when in 3D view.

As far as this task goes, it's resolved. We can add further improvements even so.

It's less of an issue here because usually you don't draw annotation layers on top of one another. But yes I think it should be consistent with GP objects.

Yes that could also solve the same issue, at least when viewed from the side view.

Why not simply put the scale handles outside the rotation gizmo sphere.

Marek: Many good points here. I largely agree, esp with the more consistent keymap comments.

Selection:
Important logic behind adding and subtracting from selection:
Shift + LMB : add to selection is ok, but do not copy it like it works in Maya.
Explanation:

I notice that we have the same problem with the list order and the Up/Down buttons.
Do we do the same as in Grease pencil: Reverse the order and keep it fixed?

I open again the task that was closed by previous commit because I'm not sure all topics of the task have been done already.

I have done the change for popover:

I second the comment above. For me, local view-specific cursor position is a problem rather than help. Every single time I isolate selection, and then go back to global view, the cursor is in the wrong position. I'd simply completely remove the idea of global/local view specific cursor, and have one cursor position regardless of 3D view mode.

I can handle the popover change

Sounds like a good idea to me.

@William Reynish (billreynish) Maybe could be useful to add a popover for the notes list as we did wiht layers in Grease Pencil. This way there is no need to always keep opened the side panel to manage the notes

Q: Both of these are incompatible with 3D viewport-specific local view cursor, how to solve? ~ ideasman42

Yes, correct. It was recently added back. This is now resolved.

What does this mean exactly? The way I understand it is already implemented.

@Campbell Barton (campbellbarton): That makes sense, and should solve the same problem.

In this case I think the solution should not be to use a blank gizmo and instead add the ability for keymap items to toggle on/off based on a setting.

Gizmos seem to be disabled when an animation is playing. 2.79 shows them, so I'm not sure if it is intentional or not.