- User Since
- Aug 15 2019, 11:40 PM (27 w, 5 d)
Mon, Feb 24
How would this work for add-ons? Would add-on developers have to create arbitrary menus in order to make their operators accessible via search? Would there be a way to filter which menus would be included in the search scope?
Are you thinking of a setup where there'd be a bone/object pointer in the TransformOrientationSlot struct, and the create_orientation operator would set flags for live vs static? I think I can see how the innards would work, but I don't have a clear picture of what that'd do to the front end.
You haven't described why the advantages aren't clear, or why you're looking for advantages (over what?) in the first place. I'd love to help you out, but it's hard to improve the patch description if I don't know what the source of your confusion is.
Sun, Feb 23
I'd love to do something like this:
@ronan ducluzeau (zeauro) It only works with object orientations. You could (theoretically) use a similar approach to create live geometry orientations from vertex groups, but you'd run into some ugly issues with modifiers.
Renamed the orientation property, adjusted the popover. Tweaked the object deletion operators to reset the orientation property when an object that's being used as an orientation source is deleted. It's a bit hacky, to be honest.
How would limiting the feature to TRANSFORM_OT_transform improve it, or improve feature parity between tools and modal operators? It wouldn't make the code any easier to maintain, it wouldn't make the feature more discoverable, it wouldn't limit undesirable behavior, it wouldn't make it any easier to use it with a gizmo; what am I missing?
The property defaults to false, and TRANSFORM_OT_translate already has it. Limiting this to just TRANSFORM_OT_translate means we can't rotate, scale, or shear the cursor from a gizmo, which runs contrary to the notion of feature parity between the tool system and modal operators.
Sat, Feb 22
This isn't quite ready for code review, but it should be ready soon-ish.
Tue, Feb 18
Do you have 'Default to Advanced Numeric Input' enabled in your input preferences?
Sat, Feb 15
Fixed issues with the Active Element pivot in edit mode. Added the property to more transform operators.
Tue, Feb 11
This is a quick and dirty layout hack for accessing a few layout engine properties. With this patch, you can tweak things like the space between items within a layout block through Blender's python console via C.preferences.ui_styles. Here are the default values for these properties, from interface_style.c:
Using a label breaks convention and messes with the column alignment. I could try to hack something together, but this is a situation where adding an icon would be easier than wrestling with the layout engine.
We could create a '4L' icon, to match the label we currently use. The icon I'm using in this revision is way too generic:
Mon, Feb 10
That'd depend on how you use it, wouldn't it? If we activated pan/orbit/zoom on drag, we could use long press as a fall-through. You'll notice a hitch if you use a larger drag threshold, but that can be fixed with a two-line tweak to wm_handlers_do.
Sun, Feb 9
Tue, Feb 4
What if we came at this from the perspective of creating a sort of selection API? Right now, we use editor state flags (x-ray mode, etc) to drive selection behavior, where we could be using operator properties that, on invoke, are set to match those flags. If we went that route, we'd be able to add an 'override global settings' property, letting users swap between their preferred behavior and the default behavior by toggling a single option. X-ray mode wouldn't change, we wouldn't have to worry about tracking a new editor state, and we'd have a framework for future selection features.
Sat, Feb 1
I can confirm this one to a degree. It seems to depend on what's in the undo history and how far back you go. In certain situations it'll change the shape key, and then change it back, as you undo.
I'll be taking another crack at this one. Current plan is to scaffold a way to test different rotation methods without having to recompile, and to do a bit of cleanup to make the technical side of it more human-friendly. The goal here is to separate the user-facing feature (tracking the viewport rotation to the 3D cursor) from the developer-facing feature (a framework for tracking to/from various views using rotation methods that help users stay oriented in 3D space), and then work backwards from there to create a design task with demo files. This should make the feedback process easier for both sides.
Wed, Jan 29
The issue is that, when 'wait for input' is true (as it is by default), the modal starts without updating the header or the status bar. The user doesn't know a modal has started, why viewport navigation is blocked, or what input the operator is waiting for. When they do figure it out, the modal starts with an arbitrary smooth value that's rarely useful.
Jan 27 2020
D6055 was accepted back in November, right? I'd been wondering what happened to it.
The gizmos can currently not access the transform operator data,
Jan 24 2020
Jan 23 2020
P1227 is a quick and dirty hack that keeps the transform gizmo visible during modal events. All I've really does is comment out the bits of code that explicitly disable the transform gizmo during modals, and add the WM_GIZMOGROUPTYPE_DRAW_MODAL_ALL flag to its gizmo group to keep it from disabling the viewport navigation gizmo.
@Paul Kotelevets (1D_Inc) Press and release events are turned into click events in wm_event_system.c, long after the platform-specific stuff is taken care of. All we'd have to do is trim a few lines here to make it work. It'd give us more information to work with in modals, since we wouldn't be overwriting the release location with press data that's already accessible through the event system, and it'd match how the vast majority of operating systems handle click events (in the 3D viewport; the UI handlers have their own logic).
It looks like D6454 tackles some of this. Should it be expanded, or should the rest be covered in a second patch?
Re: Shearing. The value that we use for shearing is the shear factor, which doesn't need a unit on its own. It maps nicely to modal mouse input, it's great for quick/arbitrary shears, and advanced numeric input lets us input the factor as 1/tan(radians(90-θ)) when we need a precise shear angle. We could add a property to the shear operator that switches the input mode from factor to angle, saving users a dive through the manual, but that's out of scope for this task.
Jan 22 2020
Calling it 'Zoom to Frame' or 'Zoom to Current Frame' would match the settings in the user preferences. Consistency on that front, whatever you end up calling the operator, shouldn't be overlooked.
The core issue still exists; call the operator via operator search. If you want a superficial fix, do this:
@Julian Eisel (Severin) Right now there isn't a fallback for un-handled click-drag events; they slide away into the ether when we could be treating them as click events. I'd rather see something like P1221 (tweaked to send the key release coordinates instead of the key press coordinates; if we need the press coordinates for a click event we can use prevclickx and prevclicky) than a band-aid solution that relies on overloaded tool keymaps.
Jan 21 2020
Just chiming in here after seeing this task mentioned in the UI channel on blender chat:
@Aaron Carlisle (Blendify) Yep, I'll do the work. It'd be rude of me to punt this late in the game.
Jan 20 2020
A potential middle-ground would be to modify WM_event_drag_threshold() to cover this fallback scenario. It'd let us set a sanity threshold, so fallback clicks aren't sent when the mouse is moved to the far side of the screen.
I believe there's a degree of intentionality behind this behavior, at least for horizontally arranged drop-down menus. I know we have used_mouse, autoopentimer, and hold_action_timer in uiHandleButtonData, but I'm not 100% up to speed on how those properties are used.
Jan 17 2020
For Windows, we're mostly looking at how Blender handles the VK_OEM_1-VK_OEM_8 range when we're talking about layout support, right?
There isn't a clean way to use radial selection alone for elements that aren't scaled or displaced to fit their arc quadrants. You could fall back to pointing when an element is under the cursor, using the wedge highlighting suggested in T56949 to distinguish the selection methods, but that's out of scope for a bug.
Jan 16 2020
Jan 14 2020
Jan 7 2020
Set 3D Cursor doesn't have a drag functionality. The move operator mapped to right click (tweak) handles that.
Exposing the leaf limit through the API might let you create a testing script to find the sweet-spots for different scenarios. If there isn't a workable middle ground between the ideal leaf limit for looping over all of the vertices in a high poly mesh and the ideal leaf limit for small brush strokes, you might be able to finesse it with a scaling factor. It'll depend on where the overhead comes from and how linearly that overhead changes, though, and we all know how that goes.
Dec 18 2019
@Campbell Barton (campbellbarton) I probably have some tunnel vision here, as I'm focusing on click-drag selection instead of the tool system as a whole. The main benefit that I see from an operator-based approach (for selection) is that it would mirror the way Blender handles transformation modes. Using a group of editor-wide settings on the right side of the tool header to change the behavior of five keymap entries in 3D View (Global) feels more approachable and explainable than a system that dynamically changes the active tool keymap in order to access twelve keymap entries spread across four tools.
Dec 15 2019
@Campbell Barton (campbellbarton) Yep, same bug. Operator properties changed via the tool header are only applied when the operator is called with workspace_tool_type set to DEFAULT. Haven't traced it further, yet, as I'm still trying to wrap my head around what all's happening in WM_event_get_keymap_from_toolsystem.
Dec 13 2019
Do you have fallback tools enabled? If you do, test it with the fallback set to the active tool versus one of the selection tools.
I can confirm this one. I'm seeing both 90° roll and 1-3° roll, compared to the normal orientation of the same face.
Dec 12 2019
Yeah, I haven't done enough with the C side of the UI code to have a good sense of how much work that'd take. @Harley Acheson (harley) might be able to give us some insights, though.
@Hans Goudey (HooglyBoogly) Here's what I did in space_toolsystem_toolbar:and complimentary tweaks to space_topbar.py:
Will we need an even-more-generalized version of the overflow popover from D5832: UI: Add the rest of bevel's options to the active tool to handle the UI end of this? Something like
Dec 9 2019
Dec 7 2019
Stupid question: What's the thought process behind using fallback tools instead of fallback operators? There are some issues in rB6ffcddc10afa with how tool settings are updated when a fallback tool is active (play around with the bevel tool and toggling 'Vertex Only'), but I'm not sure how to weigh the current implementation against a one that relies on theoretical a wrapper operator for box/brush/lasso select that sits outside the tool keymaps.
Nov 23 2019
You're right about box() not inheriting the align property, but I'm not sure if that's a bug or a design limitation. In the short-term, at least, you can solve the alignment issue by throwing a column into the box and using that as the root for the sub-layout.
Nov 19 2019
So it looks like there's some weirdness going on with what's actually returned by transform_orientation_slots.type — it returns both the type enum and the use bool in some (but not all) sub-layouts. This is probably what's causing your crash, but I'm not a 100% on whether this is a bug or a design limitation.
I can't reproduce the crash using just transform_orientation_slots, and as far as I know there isn't a  or  to call in the first place.
Nov 14 2019
It's mostly for scenarios where the 3D cursor is being used as a work plane and the user wants to manipulate the viewport relative to that plane. This lets users set the viewport to precise angles using the transform modal (using incremental snapping, axis constraints, advanced numeric input, etc), the sidebar (tweaking the cursor rotation directly), and the Set Cursor operator (using geometry alignment, etc). Instead of hard-locking the view rotation, I've set it up to feel elastic - users can rotate the view temporarily using the normal methods, and the view smoothly rotates back to the tracked angle after the rotation modal ends.
Nov 12 2019
Changed enable/disable behavior, wrapping the setting in an operator in order to take advantage of view smoothing. The view doesn't snap back to the prior view when tracking is disabled now, and users can temporarily rotate away from the cursor while tracking is enabled. I slowed down the transition speed significantly for this clip:
Nov 11 2019
Improved quad-view handling when track to cursor is enabled.
Nov 10 2019
Oct 11 2019
Launch Blender from the system console to keep the console open after it crashes. Use something like Cmder if you want to manage multiple consoles simultaneously.
This might be redundant, but have you checked your event viewer logs?
Oct 7 2019
This started somewhere between 24be998b986c and one of the October 3rd commits, I think.
Something to note is that setting the pivot to active uses the active object's origin instead of the active vert/edge/face when transforming the 3D Cursor. This has been an issue since last summer, as far as I can recall.
Oct 2 2019
That was poor wording on my part; 'a solution you're amenable to' is a better way to phrase it. My intention was to follow up on your comment about finding a very different way to solve the issues in the default implementation and clarify the scope of the conversation.
Different in terms of behavior, appearance, or functionality? I can look into incorporating behaviors like the reactive thickness based on cursor proximity, and I'd be happy to build those behaviors on top of the default appearance and position instead of what I've proposed here, but I can't tell from your feedback if that's the kind of solution you're looking for.
It isn't a critical design task, so I'm not too worried about what the final result looks like. Mostly a way for me to use Cunningham's Law to figure out how the UI team does its thing.
Would a combination of center-aligned horizontal elements and top-aligned vertical elements (or vice-versa) be better?
Oct 1 2019
Removed tab outline, reduced tab thickness, simplified arrow geometry, adjusted colors, adjusted dimensions.
I can push the design a bit, overlapping the shapes in order to break the scrollbar feel. Here it is with const short narrow = (U.pixelsize) + (int)(2 * U.dpi_fac);, which is about as thin as it'll go.
You're right about them visually crowding the scrollbar in the outliner and the expansion arrows in the property editor, but I haven't had much issue with actual interaction. How frequently do users flip and hide headers and navigation bars? I could work in some region-specific and orientation-specific accommodations.
Sep 30 2019
Blender's UI elements are definitely larger than what you'll see in 2D creative suites, but the same isn't true for 3D suites. With Autodesk using ribbons and Modo using a three-bar header, Blender isn't a significant outlier in terms of header height. UI element width and the lack of a vertical rule separator element are larger issues for the tool header right now.