I tested the tool behavior of drag-release. Some notes:

• The selection shouldn't be moving when defining the snap point after pressing B.
• The status bar should change to show the base point modal keyamp (and how to confirm it by pressing B again)

To me this works great! Thanks for making the adjustments.

In D9415#463474, @Germano Cavalcante (mano-wii) wrote:

Canceling the snap source edit was not really useful as users will prefer to cancel the operation and try again in such cases.

Agree.
Btw, can't test the linux D9415 build for some reason (unpack error)

In D9415#463977, @Paul Kotelevets (1D_Inc) wrote:

(...)
Btw, can't test the linux D9415 build for some reason (unpack error)

I don't have a linux used to test.
Have you tried downloading again? (Maybe it could have been the error during the download)
https://builder.blender.org/download/patch/D9415/

Tested on windows. The general mechanics looks and feels nice for both modals and active tools, tried grab, rotate, scale, extrude (G.E.A.R.S.)
Lovely! First impression is very positive.

Has got some application stability issues (hard to name the reason, Windows build didn't unpacked several files because of a long file names/paths, probably a folder packed by builder has too long name)
Also, has got local issue with zero angle values but not sure which level the problem belong to, since we are familiar with it for quite a long time.
Here is an example if is interesting.
Rotating selection from point A to point B along global Z axis will make selection disappear in both object and edit modes with both modals/active tools.

Hi Germano, some suggestions based on a chat I had with @Pablo Vazquez (pablovazquez)

1. Show the base point indicator after you set it (right now we don' t show anything).

For now it can be as simple as the circle with a different color (e.g., the orange we use for select).

2. Name the action "Set Snap Base"

Now besides this, I think we could optionally have the following behaviour for gizmos:

• Press B -> enter the Set Snap Base mode (mouse can be released)
• Click to confirm the base point -> enter a confirmation mode for the final position
• Click to confirm the snap to point.

This 'confirmation' mode is the same as if the user had used the transform operator and set a constrain before pressing 'B'

In other words:

• In fact the gizmo should no longer be drawn (but the constraints should still be drawn).
• The extra shortcuts in the footer are no longer needed.

It will be more comfortable. I wonder if it is intuitive enough though. But we can even keep both options co-existing.

In D9415#464021, @Dalai Felinto (dfelinto) wrote:

as oppose to keep dragging the gizmo.

It will be more comfortable. I wonder if it is intuitive enough though.

Sounds like entering modals mode from active tools. This can works as unifying behaviour (as a result, there will be no differentiation between active tool and modals in basepoint snapping behaviour).
Resetting the transform of a selection after pressing B for providing a source for a snap base will indicate the moment you can release LMB after gizmo dragging and use it for picking snaps, sounds clear and quite intuitive at the concept level.
Will be interesting to test.

Tried January 18, 04:50:55 build.
It is usable, but the main problem is an empty LMB release that does nothing, which is quite disturbing in my opinion.
I think it is a nice strategy to switch modals from active tool in complex cases like basepoint snapping (modals has benefits in complex cases because of a better flexibility and resulting expandability than active tools), but, AFAIK empty actions are not presented anywhere else across application.
I would like to suggest another behavior.

Compromise A - something in between the two already presented:

• Start drag gizmo holding LMB
• Pressing B starts Basepoint snapping mode, gizmo disappears, snap mark appears.
• pressed mouse aims snap base
• LMB release confirms snap base
• second LMB click aim and confirm snap target. (in further possible tools design that may require several clicks, all subsequent clicks will be performed with regular mouse clicks)

Benefits over the first way - no functional mouse substitution (B is never used as LMB click)
Benefits over the second way - no empty LMB clicks, I think that this way the transition between active tools and modals can be smoother, since it allow to avoid emtpy LCS releases.

Benefits of the first way - quite fast
Benefits of the second way (by Dalai) - only clear clicks (press+release) are used for snapping.

There is another possible solution to the empty LMB release

Compromise B - to not to show snap marker after pressing B (which hides gizmo and resets transform of a selection) and before mouse release. Such a behaviour will make LMB release after grabbing gizmo nominally not empty (so you will not expect, for example, picking basepoint snap on LMB release or so, which is quite confusing at the moment in the latest build)

LMB release confirming snap base seems like a good way to go.

Before implementing it (at least for testing), I'll wait for @Pablo Vazquez (pablovazquez)'s feedback (since the idea of allowing LMB release came from him).

Oh, I forgot to inform, the zero angle rotation snap issue has been fixed in rBdcb37959d467 :)

@Germano Cavalcante (mano-wii) right now the "x" snap mark appears as soon as I press B, and disappears as soon as I confirm the snap base. It should be the other way around, it should only show when I press B, and stick around after that.

In D9415#464288, @Germano Cavalcante (mano-wii) wrote:

• rebase onto master

For some reason unrelated to the patch the builds for windows are failing in the buildbit.

Yes, but I figured out how to unpack linux builds (changed archive manager to installed by default)
Tested January 18, 15:50:46 03fe0b1ae303 linux build (is there other way to differentiate builds with different behavior?)
Yes, a behavior presented in this build has a smoother transition from active tools to modals (LMB release picks snap base on a fly, and the regular click set snap target), but I think that proposal by Dalai assume basepoint operating with two regular clicks.
Avoiding pressholdings during snapping may be a wise decision, if to follow a pure modals way. However, we are transitioning from gizmo using, which is all about snapping during pressholdings.

In D9415#464299, @Germano Cavalcante (mano-wii) wrote:

• Only display the Snap Base "x" indicator when confirming the "Set Snap Base" operation (or when the snap to "Edge Perpendicular" is activated as this is an already existing feature and is useful to guide the user in this case)

tested January 18, 16:20:55 1c810d2d4615. It looks very similar, not sure if I got the difference.

So I think we need some feedback from Pablo and Dalai about their proposals.

I tested it again and it works great! Very intuitive.
The updated behavior should cover all workflows as far can I see and the visual feedback is very helpful!

we need this too.thank u @Germano Cavalcante (mano-wii)

In D9415#350442, @slowburn (slowburn) wrote:

Just tried the build and it works great for translating objects. The new indicator to show the average of multiple snap points is a nice touch as well.
However rotating and scaling doesn't actually benefit that much from picking a single reference point ('snap source' in this case), since the transform center is still set to object origin. This means that the user still has to manually move the object origin or place the 3d cursor at the desired transform center, like shown in the example of an impractical use in task summary. It would be much better to implement a proper 3-point reference transform for scale and rotate.
Here's what I mean:

Scaling would use the same principle: first 2 clicks set scaling center and initial dimension, then 3rd click sets final dimesion.
Also, could you add a toggle somewhere in the snapping menu to enable source picking by default? So that pressing G, for example, would go straight into interactive mode. That would be a huge timesaver for certain tasks.

@pooya (pooyapower) thanks for the feedback, but moving the pivot point is kind of a separate thing.
The 'snap source' (Snap Base in the UI) has always existed. The patch only proposes to make it more visible and allow it to be editable.

@Germano Cavalcante (mano-wii) Congratulations! I look forward to using this. Well done!

Hi!
I tried January 18 build. Snap mechanics looks nice, but base point cross sign behaves weird at the moment.
For rotation it's angle seems to be doubled.
A GIF:

Thank you!

I think this patch reveals an important feature with a compact solution. Feels very usable

Played with this a bit, I like how this generally works well with non-mesh objects too. Especially had fun using this with bone editing.

Only thing I find broken is grease pencil edit mode. This doesn't detect grease pencil points as snap points. (Maybe not worth to look at right now since GP 3.0 is coming?)

In D9415#469370, @Germano Cavalcante (mano-wii) wrote:

• Rebase on master

Hello, good evening. I did some tests and everything works great but I found something that I think is an error: When I have a curve object in object mode the snap (Snap With: only Closest mode) does not work as expected (this without using the new functions (B))
Blender 3.5 New Snap:

Blender 3.1 Old Snap:

See you soon, I'm happy for the new Snap

After a little bit more test:

• Interactive snap can be enabled during/after numeric input. I think interactive snap doesn't really work or isn't useful here.

• I'm not really sure how interactive snap works with edge/vertex slide.
  • After activating slide? (G G B B?) Interactive snap does not activate while sliding.
  • After the first G? (G B B G?) Interactive snap works with the first G, but as soon as slide is activated, it disappears, and for some reason it activates the usual snap mode (the magnet icon) instead (video below).

In D9415#469401, @Sun Kim (persun) wrote:

Only thing I find broken is grease pencil edit mode. This doesn't detect grease pencil points as snap points. (Maybe not worth to look at right now since GP 3.0 is coming?)

@Sun Kim (persun), this patch does not touch the grease pencil code.
Grease pencil editing was implemented by the Grease Pencil team who handled snap support.

Interactive snap can be enabled during/after numeric input. I think interactive snap doesn't really work or isn't useful here

In fact it doesn't seem to be useful to keep the input number after changing the base snap. But changing the snap base after inputting some value doesn't seem to be useful either. It's something to consider though. But personally I don't see it as something impactful that should keep the current solution on hold.

I'm not really sure how interactive snap works with edge/vertex slide

The feature has only been implemented for Move, Rotate and Scale. Other modes such as Edge Slide, Vert Slide and Trackball were not included.

Interactive snap works with the first G, but as soon as slide is activated, it disappears, and for some reason it activates the usual snap mode (the magnet icon) instead (video below).

Taking advantage of things that have been set in one mode to be used in another is something to consider. (Maybe it's better to support Vert Slide and Edge Slide to avoid these oddities).

In D9415#469583, @Jhon Rincón (JhonR3d) wrote:

Hello, good evening. I did some tests and everything works great but I found something that I think is an error: When I have a curve object in object mode the snap (Snap With: only Closest mode) does not work as expected (this without using the new functions (B))

@Jhon Rincón (JhonR3d), this patch does not touch in the Closest "Snap With" mode.
This mode works with the object's Bounds.
You can better understand what is happening by visualizing the bounds of the Object Curve (In Properties → Object Properties → Viewport Display → Bounds)
Note that the radius of the curve is currently also affecting its bounds (See T103387: Set Curve Radius is Effecting Bounding Box of Curves)

In D9415#469690, @Germano Cavalcante (mano-wii) wrote:

• Support Vert Slide and Edge Slide modes

These modes also support Snap Base and snapping elements, so instead of preventing the user from editing the base snap, implement the feature for these modes as well.

Sounds interesting!
Does this mean explicitly display the actual closest point during operation, so you can see the point that is actually snapped instead of guessing it, or the ability to set it manually?

Tried Feb 04 build (unfortunately, Feb 06 build is MAC only, can't test it), there is no ability to set basepoint during slides, but there is the ability to see the closest point, which is informative.
Found an issue with basepoint calculations (basepoint of top or bottom part of a loop is calculated wrong depending on which side mouse is closer at operation start), but not sure if such issues belongs this tread and such an operation can't be considered as precise anyway.
A video and blend in case if will be useful.