Testing,

it would be good if this patch snapped before dragging on the ruler, this was one of the main advantages of using the gizmo.

Although if this is a bigger task, it could be separated into another patch, since this is at least no worse than current functionality.

This seems like something that should have some UI team involvement? Is there a design task, or at least some mockups/screenshots to see what this looks like or how it works? (Found this by accident)

In D7071#178211, @Julian Eisel (Severin) wrote:

This seems like something that should have some UI team involvement? Is there a design task, or at least some mockups/screenshots to see what this looks like or how it works? (Found this by accident)

The description has been updated

Getting some compile warnings here:

/src/blender/source/blender/editors/space_view3d/view3d_gizmo_ruler.c: In function ‘ruler_state_set’:
/src/blender/source/blender/editors/space_view3d/view3d_gizmo_ruler.c:274:39: warning: unused parameter ‘C’ [-Wunused-parameter]
  274 | static void ruler_state_set(bContext *C, RulerInfo *ruler_info, int state)
      |                             ~~~~~~~~~~^
/src/blender/source/blender/editors/space_view3d/view3d_gizmo_ruler.c: In function ‘view3d_ruler_item_mousemove’:
/src/blender/source/blender/editors/space_view3d/view3d_gizmo_ruler.c:360:14: warning: variable ‘prev_point’ set but not used [-Wunused-but-set-variable]
  360 |       float *prev_point = NULL;
      |              ^~~~~~~~~~
/src/blender/source/blender/editors/space_view3d/view3d_gizmo_ruler.c: In function ‘gizmo_ruler_invoke’:
/src/blender/source/blender/editors/space_view3d/view3d_gizmo_ruler.c:986:23: warning: comparison is always true due to limited range of data type [-Wtype-limits]
  986 |   if (inter->co_index != -1) {
      |                       ^~

Great task! Just throwing couple of ideas in, if i understood the scope of this task correctly...

Perhaps @Germano Cavalcante (mano-wii) you could consider giving the option to the user to spread the crosshaires of the cursor a little bit so the gap between them would be more prominent. The design idea of this gap in crosshaires in general was to make target selection more efficient - user's view of the target is not obstructed by the middle crossing of the crosshair lines.

Do you mean changing the cursor design?
While it is interesting, this is not something that an operator can edit. This type of design is in a different area.
I would start to escape the scope of this patch.

Ah, ok. Sorry for the off-toppic.