Current Booleans indeed cannot reliably work on open geometry. We would have to wait for the new Boolean implementation, which is supposedly not that long.

@Debuk (Debuk) ...which is why I am proposing to make it into the move manipulator :) That's already subject to pivot point and transform orientation settings. With current modal rip operator, you always move in view plane, and have to rely on hotkeys for axes. With a manipulator (+individual origins +normal orientation) you would just pull the Z handle.

Your object, Grooves 02.001, contains a topology mistake which makes the Boolean's job difficult. Looks like you've dissolved one of the faces (by mistake?) and overlapped two vertices. This is not a bug.

@Debuk (Debuk), yes, for the proposed solution with overlays the decisionmaking for rip would need to be augmented: existing behavior with the modal operator makes some sense (although still is often puzzling, esp. when ripping multiple disjointly-selected areas). My proposal suggests making this decision an explicit and editable step, which shouldn't be based on gizmo position at all.
As for the gizmo, I think it should be the move one (or, in an ideal world, a switchable between move, rotate and scale), as that is what the operation does: edge split, "smart" selection and move. Proposed in T70047 the gizmo is just a circle, whereas a user expecting to move something should generally expect the move gizmo (IMHO).

Can't reproduce here with the specified Blender version.

See also T47041, and its recent manifestation on BA. Blender lacks general awareness of custom normal data for tools and modifiers.

...though it is a bit weird since there are different methods for Bevel, Width being one of them.

IIRC recently there was a report about undo crashes when opening a file from older version. Judging by the workspace layout, perhaps the startup file was also transferred from an older version, and is subject to that issue? Can't for the life of me remember the task though :(

Regarding the rip tool, I think the actual gizmo should just be the move manipulator, as that's the action performed on ripped vertices/edges. Perhaps an overlay could be introduced: when the tool is active, it would highlight edges along the side that's going to be ripped, with the ability to click a given section to switch the ripped side:

T65397 is resolved, this one isn't.

That's because the "Show Tool Settings" is enabled by default in that workspace.

Info updated. I'm not sure how "duplicate" it is, the behavior is different, though cause indeed may be the same.

What are you talking about? Final orientation is already known and is represented to the precision available. Aligning an object should match that orientation to the same precision, not approximate it. It's not about rounding of final result, at all.

No. That thread talks about inaccuracies that accumulate while editing. These are indeed to be expected. Aligning to orientation is not a temporal operation. It should, if at all possible, match the object's orientation with the desired one, otherwise it's at best a "Try to align". Right now it's just calculated with floats, which contributes to the discrepancy listed in the task description.

Cannot reproduce, armature adds just fine here.

It's not a question of whether the object was imported, it's a question of whether the object has UVs. When it doesn't, there's nothing to map the texture with, and of course the UV editor window will be empty.

I'd generalize this a bit. When Affect Origins is set, most of the transforms seem to indeed affect origin only (i.e. Object -> Transform, Object -> Mirror). Unfortunately, neither the Transform panel, nor Object -> Clear operators seem to be aware of that setting, and still affect the object, and not just origin.

@Germano Cavalcante (mano-wii), updated the task as requested. Sorry, I assumed this would be looked at in concert with the other task.

I don't think there's a key combo for that, no, but neither do I think someone would just do that "accidentally", hence my thinking that an add-on might be responsible.

IMHO, this is a mis-feature at this point. The first thought when seeing this in 2.82 for the first time was "no, no way in hell". And I'm a vim user.

You've somehow disabled bone selection in viewport for both pose and edit mode. Enable it via the outliner:

Could be related to T71295, seeing as in both cases these are macros.

What in the... what?!? Paper cuts? For this, really?!

It is perhaps not very intuitive, but that's how it's supposed to work. Box selection doesn't change the active object, because it has no sense of selection order. Active object doesn't have to be selected.

Looks the same with 2.79. 2.78c behaves correctly.

That's what mirroring along an axis is supposed to do. Would you mind attaching a .blend that illustrates the issue?

That is because the Annotations overlay is by default disabled in the Sculpting workspace, along with grid, 3D cursor, etc. If you need it, simply turn it on.

Different tools. Ctrl-RMB is bound as lasso select for the whole 3D view, i.e. in this case it works like object selection tool.

I agree in principle, though I'd rather like some unified API for backup/restore that could be used with other edit modes as well. Do you have any advice on how to proceed from here?

Try looking at the status bar for key hints when the circle select tool is active. The UI doesn't lock up, that's just how the circle tool used to work.
In 2.80 and up, you can instead set your selection tool to be Circle in the toolbar. That one uses new keymap and allows you to navigate.

Active object can be edited even when unselected. That's not a bug.

AFAIK, internally you do do this via internal undo for pretty much every interactive operator. But that's not exposed to Python :(

Can't. Just be strategic with your mouse moves, I guess. I.e. set yourself up for quick deselection of unwanted things. Some sort of option to not select occluded objects unless their unoccluded parts are actually in the box could be nice though.

PF_REMOVE (the '<UNKNOWN ENUM>' here) is just not exposed to the Python API, and only set internally when generating that menu. Presumably because it's unsafe, i.e. if the file does not actually exist, data would be lost when file is closed, unlike 'USE_ORIGINAL', that would actually write to file if it doesn't exist. Exposing it is trivial, but it'd be nice to see the devs' rationale on it.

In outliner, there's no 'Scene' now. There's 'Scenes'. Which shows all scenes in the file. Tree organized by collection is 'View Layer', not 'Scenes'.

A user with no experience? Can't know that. One could even argue that they even shouldn't know that. But that's not a topic for here, I guess.

That the brush is SculptDraw should be a clue though. Box/lasso masks aren't brushes. Click drag adds, ctrl drag subtracts.

And it won't, because it's triangles. Loop cut cuts through quad strips. That it even adds a vertex on first use is kind of surprising. If you want to cut a loop through those edges, select them all, and go Edge -> Subdivide. You can select them all quickly by selecting the top vertex first and then converting to edges (Ctrl+2).

Yes, I've just updated my installation and am also getting this. Probably just need to wait a bit for Arch to catch up, and in the meantime use the official bundle from blender.org.

Just to point a couple of things out, though this discussion is probably better suited for rightclickselect than here:

That specific default hotkey was neither fast or efficient, but that's beside the point. This is not a bug: different keymaps exist to have different, uh, key mappings. That's their purpose. Choose one you like, and build on it by assigning your own hotkeys. Furthermore, with the 2.81+ origin transforms, you may well find that those operators lost quite a bit of their use. But if you don't, assigning your own is the way to go.

Should it be there is the question though. Different keymap - different keys.

Same as T70998?

Thanks for clarifying.

The Box tool in object mode has always selected through objects, this is not a bug.

Which description are you referring to? Tooltip for the Tweak tool says "Select and activate item(s)", it doesn't say anything about the 3D cursor. Perhaps it should also say "move item(s)"...

The point is that when set to Drag, the gizmo doesn't steal clicks when you want to click something that's near one of the gizmo elements, for example a vertex that's inside the move tool circle, or near one of the move tool axes. The tool will only start moving when you actually drag it, single clicks will go through. If you were expecting to "activate" a single move axis like in Maya or Max, the move tool doesn't work like that in Blender.

(1) is the current behavior already
(2) is in the 2.81's new outliner, you may want to try the beta
(3) if you modify scale via the 3D view side bar, or the Object button in Properties, only the active object is modified. That's not a bug. If you want these changes to propagate to other selected objects, you can hold Alt while modifying the slider(s), or right click a slider and pick Copy All to Selected or Copy One to Selected, to copy the whole scale vector or just a single dimension.
(4) There is already such a button in the material specials menu (the button with a down arrow, under the "+" and "-"). Or in 3D view, Object -> Make Links -> Material does exactly that.

That's not a bug. When you join the objects, the joined meshes are copied into target mesh, but the original meshes remain in the data, with 0 users, still referencing the material. The same would happen if you simply delete the duplicated objects. When you reload, those meshes are purged, so the extra links disappear. Or you can purge them manually via the outliner (Orphan Data).

But if you export with, say, "-Y" forward, and then import with "Y" forward, then naturally the orientation wouldn't match :)

You're welcome. Like I said, I tried to show all the steps and tools in the video, so you could see how they work and have keywords to search for in the documentation for additional information.

AFAIK, it has been like that since... pretty much since dissolve existed, I guess. So it could be dubbed a historical notabug :) Joking aside though, this kind of geometry is rather nasty, so if user-facing tools can be made to avoid creating it, IMHO it should be done.

Vertex groups are weird, their data is part of the mesh data block, but the groups themselves belong to object. Alt+D should work though, what do you mean by "not the same"?
You can transfer groups to linked objects via a menu, in vertex groups there's a button with a down arrow under the "+"/"-" buttons. Click that, and you should find an option to Copy Vertex Groups to Linked.

Simply closing off may not be 100% sufficient here, as the modifier might then generate inverted faces. Booleans in Blender (at least for the time being) like simple geometry, and despise open geometry and tiny faces, overlapping faces, etc. Attaching a video on how to fix your mesh for a clean Boolean operation. For clarity on what's going on, I tried not to use any hotkeys, except Shift+B (zoom to rectangle), and Ctrl+R to insert the five cuts back.

In 2.80 and 2.81, I just exported the object from the STLTest1 file, imported in back, and it kept the orientation. Note that you can pick the orientation you need both in the export and import dialogs, and if you change it in the import dialog, it'll remember what you picked when you import again.

Here it only breaks if you subdivide in sculpt mode, which I guess is the point anyway. In my case the "breaking" is random polygon streaks from fingers and toes. It doesn't break when subdivided in object mode though.

@Rodger Davis (RodDavis), unless you mean to tell me that on your system and graphics card (which are irrelevant in this case) you're not able to reproduce the issue, the report shall stay as is, thank you very much.

Sorry, the commit hash doesn't mean to imply that commit broke the tool (i.e. the 'mention'). It's simply the hash of the beta build used.

To add to what @Aleksander Tarkhanov (stark) said, when you already have a loop and need to slide it, shift+v (Vertex Slide) isn't necessarily the tool you want to use. Look in the tool buttons on the left, fourth from the bottom should be the Edge Slide. This tool slides whole edges (you need to select them before using it). A default hotkey for invoking it directly is gg (not a typo, that's double tap g).

Perhaps a case of enabled proportional editing?

Works fine here. Given this and T70950, are you certain your Blender installation is OK? Perhaps some broken add-on?

Works fine here.

That tool in default keymap is not activated by the B key. That button cycles different selection types that are performed on tweak event, with the W key. You'll find it under that binding.

@Jacques Lucke (JacquesLucke) a warning could be a good thing for UX. People seem to run into this on a regular basis.

Works fine here. Sound like a user error, though I can't off the top of my head think of why it would behave like that.

As to why the file is 35Mb: Blender does not delete orphaned data immediately, only when you reopen the fie. You can see it if you switch the outliner to show Orphan Data. You deleted the objects, which made their meshes orphaned (0 users). On next reload, i.e. loading the file attached to this report, the meshes are removed, which then makes all the materials orphaned. This is what you will see in Orphan Data in this file, it'll show +99 Materials, though it would appear there's actually almost 1800! Anyway, if you save this file again and reload it, materials will be removed, but images are only orphaned. Finally, saving and reloading again gets rid of the images as well.

You've set the far clipping plane too far, resulting in very poor depth precision, resulting in knife not being able to project properly. Open the N key sidebar and lower the Clip End value in View to something like 1000 or even less.

In "other applications", i.e. in a file browser, with situation as presented, a selection would've been made from the bottom torus to the top. Instead, current outliner breaks existing selection and makes a new one. It may well be working as designed, but then that means there's something wrong with the design.

In the same vein, using extend selection:
In outliner, click on Camera, ctrl+click on Cube, ctrl+click on Cube again. In 3D viewport, the Cube is still active. In outliner, it isn't. And again, attempting to shift+select from that destroys selection and resets active object.

@Nathan Craddock (Zachman) see also T70852.

Collapses just fine here, same Blender build, also on Linux.

@Nathan Craddock (Zachman), not quite. The common confusion would be that in Blender (not other applications), shift+click is indeed "extend selection" not just in Outliner, and it activates the clicked item. It works like so in viewport, Object and Edit modes, in node editor, in graph editor, pretty much in any other editor. Which object/element is "active" matters in Blender, and matters a great deal, so does being able to set it. "Choosing" to not modify it for convenience of implementation and thereby breaking the common selection pattern used throughout the application is... questionable.

Confirm, since 2.81 beta, indeed, shift+clicking doesn't change the active object. Ctrl-clicking does though. Maybe the author could put a bit more info on the new control scheme into release notes?

A bug in the design is still a bug. The behavior is unexpected, moreover it's inconsistent across Blender's paint modes:

@Jacques Lucke (JacquesLucke) No, Emission shader doesn't look like a shadedeless object, as it's still subject to viewport shading in solid view. Yes, there is Flat lighting, but it affects everything. I'm talking about selectively making objects shadeless. Feature regression is not a bug?

Tried here also on a Linux machine with 2.81 Beta and 2.82 Alpha, view rotates just fine. Perhaps you accidentally changed the keymap to Industry Compatible? That one navigates using alt+mouse buttons instead of the middle button. Try loading the Blender keymap in user preferences.