@Colin Kinloch (ColinKinloch) I see - yes I guess this change makes sense. But, Blender makes heavy use of keyboard shortcuts without holding modifier keys - shortcuts like G, R, S and others. It would be inconsistent if those still were in DVORAK, but anything with a modifier (Shift, Control, Command, Alt) was using QWERTY.
Jun 4 2019
This took me a long time to understand from the confusing and sparse description. It would be much easier if you just described what this was for.
It's not clear from your description:
ok - it's possible that some old beta install caused this issue. Marking as invalid.
should be the same
We should probably just copy what we did for text objects here.
I cannot reproduce this issue.
Try doing File>Defaults>Load Factory Settings and re-test.
@Alessio Monti di Sopra (a.monti) the re-ordering refresh issue is unrelated to this patch. Only showing constraints in the Outliner for objects and not bones, is a bit of a shame indeed.
@Alessio Monti di Sopra (a.monti) What doesn't work properly? Here it seems to work correctly.
Seems to work correctly.
This seems fine to me. As you point out, there are potential conflicts if you add both a force field, plus an image to the same Empty object, but we already have the same issue with Collection Instances, so I think that's ok.
Jun 3 2019
This seems to work well now.
@Jacques Lucke (JacquesLucke) Ah yes, sorry, you are right.
At least here, the minimum scrollbar size is now HUGE:
This doesn't take UI scale into account
Update: DOF does work on a laptop with integrated graphics. Apparently the issue is driver-specific
†his isn't a place for user feedback. Use https://devtalk.blender.org/c/user-feedback instead.
Following your steps, the mirror effect looks normal.
You are most likely probably using Filmic View Transform?
Please don't use bug reports as a support & learning forum.
This is a known issue which I think has already been reported several times. Wires are always 1px thick on macOS due to newer versions of OpenGL deprecating the way in which Blender draws thick lines.
This is intentional, so that you can select items behind the gizmos.
Jun 2 2019
Confirmed ion macOS.
This is simply a bug - probably caused by the recent display changes to Edit Mode. in X-ray mode, when using face select, face dots should always show.
@Ludvik Koutny (rawalanche) The default drag distance *is* already 3px for mouse input, but there's a bug that means it sometimes uses the wrong threshold value, which is why it's currently inconsistent.
Well, what makes them feel sluggish atm, is also the fact that it often uses the wrong threshold, which is too large.
I agree that this is missing, but it's missing on a lower level, not just in the UI layer.
Jun 1 2019
Indeed, can confirm. Doesn't happen every time - seems to only happen the first time you drag after enabling the gizmo.
What is mostly needed is a developer to implement it, that's all.
@Hadrien Brissaud (hadrien) Hopefully yes, this is an area that can improve - especially with dynamic brush previews.
May 31 2019
Afaik this will happen with any keymap if you make it empty. Not sure if we consider that a bug.
@Campbell Barton (campbellbarton) It seems this gizmo got affected by the recent changes to use drag events. I think we should not consider this gizmo a drag-gizmo - it's not important that you can select items under it. Better to keep it always working.
The Select tool should really be called the Tweak tool. It is meant for clicking and dragging to directly move items. There is a reason why it is separate from the Move tool.
May 30 2019
@Zino Guerr (Zino) you can customize this in the keymap
This was resolved
@Howard Trickey (howardt) isn’t it just a matter of setting the operator context to invoke?
@Clément Foucault (fclem) is this a known issue?
Try doing File > Defaults > Load Factory Settings and report back
Another name change we could do is to the term Make - as in Make Links, Make Parent, Make Single User, Make Meta-Strip, Make Local, Make Proxy, etc.
May 29 2019
Well, to be able to use this for gizmos, the threshold has to be quite small. 3 pixels is roughly what other apps use, and I think it’s enough for mice at least. Higher thresholds make gizmos unacceptably sluggish IMO. For still and pens we can keep a higher threshold.
This allows for box-selecting markers by dragging from empty space.
Indeed this seems to work
This works well for mice.
@Campbell Barton (campbellbarton) No, afaik that is for click event detection, not drag events. 10 pixels is way too high for drag events.
@Campbell Barton (campbellbarton) Well as I said, with a drag threshold of 10 pixels, gizmos feel unreasonably slow and sluggish. My proposal would be to lower the drag threshold to 3 pixels instead.